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EXECUTIVE  SUMMARY 


PROBLEM 

In  recent  years,  Virtual  Reality  (VR),  often  called  Virtual  Environments  (VE),  has  received 
considerable  attention  among  training  developers.  This  is  due  in  part  to  media  hyperbole  over 
applications  of  VR  in  the  entertainment  industry,  but  even  more  so  because  training  developers 
recognize  the  potential  of  VR  as  a  flexible  and  effective  training  medium.  Demonstrations  and 
evaluations  of  VR  training  systems  can  help  define  the  appropriate  use  of  VR  technologies  to 
achieve  their  potential. 

Coming  to  grips  with  the  elements  related  to  the  production  of  any  training  system  requires 
the  development  team  to  conceptualize,  plan,  and  effectively  execute  activities  that  will  result  in 
a  fully  functional  trainer.  Add  to  the  already  complex  nature  of  this  task  the  employment  of  a 
leading  edge  technology,  such  as  VR,  and  you  substantially  increase  the  risk  and  difficulty  of  the 
process. 


OBJECTIVE 

The  objective  of  the  Virtual  Environment  for  Submarine  Shiphandling  and  Piloting  Training 
(VESUB)  project  was  threefold:  (1)  to  develop,  demonstrate,  and  evaluate  the  training  potential 
of  a  stand-alone  virtual  reality-based  system  for  Officer  of  the  Deck  (OOD)  training;  (2)  to 
determine  if  this  system  could  be  integrated  with  existing  Submarine  Piloting  and  Navigation 
(SPAN)  training  simulators;  and  (3)  to  determine  the  viability  of  virtual  reality  technology  as  a 
training  tool.  This  report  looks  at  the  overall  project  from  a  chronological  perspective,  the 
teaming  strategy  planned  and  implemented  in  the  accomplishment  of  the  VESUB  effort,  and  the 
programmatic  and  technical  lessons  learned  over  the  course  of  the  project. 


APPROACH 

VESUB  was  developed  by  an  integrated  team  of  government  and  industry  members  who  were 
able  to  simultaneously  address  the  technical  issues  related  to  building  a  VR  training  system,  the 
task  related  elements  of  submarine  shiphandling,  and  the  usability  and  training  effectiveness  of 
the  system.  The  goal  of  the  VESUB  project  team  was  to  assemble  and  harness  the  knowledge 
and  skills  necessary  to:  (1)  fully  understand  the  piloting  and  navigation  task  that  was  to  be 
trained;  (2)  support  the  modeling  and  programming  necessary  to  create  and  operate  within  the 
virtual  environment;  and  (3)  design  and  implement  an  effective  instructional  design  that  would 
ensure  task  related  knowledge  transfer. 

The  VESUB  research  team  included  research  psychologists,  visual  engineers,  computer 
engineers,  and  submarine  subject  matter  experts.  Nichols  Advanced  Marine  Enterprises  (AME) 
integrated  the  software  and  hardware  elements  for  VESUB.  To  save  time  and  money,  VESUB 
was  developed  by  leveraging  AME’s  Virtual  Ship  application,  a  commercial  product  that  has 
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been  used  for  several  years  to  train  surface  shiphandling  tasks  in  a  rear  projection  theater 
environment. 

Subject  matter  experts  (SMEs)  were  drawn  initially  from  fleet  training  and  operational 
commands.  However,  to  meet  the  demands  of  daily  development,  Sonalysts,  Inc.  was  placed 
under  contract  by  NAWCTSD  to  provide  SME  support  focused  on  submarine  piloting  and 
navigation,  as  well  as  general  submarine  operations. 

The  VESUB  technology  demonstration  system  used  a  high-resolution,  head  mounted  display 
(HMD)  to  provide  the  trainee  with  a  simulated  360  degree,  3D  visual  representation  containing 
many  of  the  required  cues  associated  with  harbor  and  channel  navigation,  as  well  as  accurate 
cultural  features  and  varying  environmental  conditions.  A  speaker-independent  voice 
recognition  and  speech  synthesis  system  was  used  as  the  primary  interface  for  communications 
between  the  trainee  and  the  computer  generated  autonomous  agents  (simulated  ship’s  personnel) 
to  control  the  system.  This  provided  a  communications-training  element  for  this  complex  task. 
Visual  scene  rendering,  computation  of  harbor  currents  and  wind  effects,  and  operation  of  own 
ship  and  other  traffic  ships  required  state-of-the-art  computer  systems  and  software  applications. 


RESULTS 

As  the  VESUB  effort  matured,  it  became  increasingly  clear  that  effective  development  team 
interactions  would  contribute  significantly  to  the  success  of  the  project.  Team  management  and 
communications,  along  with  technology  related  issues,  required  the  development  of  various 
conferencing  and  other  communication  methods  to  control  development  and  system  verification 
at  the  two  primary  work  sites  of  NAWCTSD  and  AME.  These  methods  did  not  always  result  in 
a  thorough  understanding  of  issues  by  all  team  members. 

The  VESUB  project  culminated  in  a  two-phased  Training  Effectiveness  Evaluation  (TEE) 
conducted  at  Submarine  Training  Facilities.  The  TEE  used  Navy  personnel  as  subjects  and  was 
documented  in  NAWCTSD  Technical  Report  98-003.  The  results  of  the  TEE  demonstrated  that 
the  VESUB  technologies  provided  effective  training  on  shiphandling  skills  for  novice  and  expert 
alike.  The  generalizable  nature  of  the  findings  also  supports  the  potential  for  VR  as  a  training 
delivery  modality. 

Through  the  course  of  the  VESUB  effort,  several  important  lessons  were  learned  by  the 
project  team.  Some  were  technical,  and  others  related  to  the  nature  of  the  development  of  a 
system  through  the  team  process.  Details  on  these  lessons  are  presented  in  this  report,  along  with 
the  project  chronology  and  a  technical  review  of  the  project. 


CONCLUSIONS  AND  RECOMMENDATIONS 

The  VESUB  TEE  clearly  demonstrated  that  a  VR  training  delivery  system  could  provide 
effective  training.  However,  there  are  still  several  areas  where  additional  research  and 
development  is  needed.  Among  these  are  the  refinement  of  the  voice  recognition  and  synthesis 
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system,  development  of  artificial  intelligence  to  be  used  (in  conjunction  with  the  voice 
recognition  and  synthesis  processes)  to  support  communications  logic,  and  the  development  of 
the  specialized  virtual  crew  concept  to  automate  and  improve  system  performance.  Additionally, 
visual  scene  improvements  that  will  better  demonstrate  real-world  environmental  issues  (such  as 
currents,  eddies,  earth’s  curvature,  and  image  contrast)  and  improvements  to  VESUB’s  software 
integration  process  are  necessary. 

The  following  conclusions  and  recommendations  are  discussed: 

•  VESUB  provides  effective  shiphandling  training 

•  Team  communications  is  a  must  in  the  development  of  complex  systems 

•  Legacy  based  system  development  must  be  closely  evaluated 

•  Configuration  management  is  essential  for  success 

•  Complex  scenes  require  sufficient  fidelity  to  support  training  requirements 

•  VE  offers  unique  presentation  capabilities  that  should  be  exploited 
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INTRODUCTION 


PROBLEM 

In  recent  years,  Virtual  Reality  (VR),  often  called  Virtual  Environments  (VE),  has  received 
considerable  attention  among  training  developers.  This  is  due  in  part  to  media  hyperbole  over 
applications  of  VR  in  the  entertainment  industry,  but  even  more  so,  because  training  developers 
recognize  the  potential  of  VR  as  a  flexible  and  effective  training  medium.  Coming  to  grips  with 
the  elements  related  to  the  production  of  any  training  system  requires  the  development  team  to 
conceptualize,  plan,  and  effectively  execute  activities  that  will  result  in  a  fully  functional  trainer. 
When  a  new  technology,  such  as  VR,  is  added  to  an  already  complex  task,  the  risk  and  difficulty 
of  the  process  is  substantially  increased.  To  successfully  meet  the  demands  of  the  project,  the 
Virtual  Environment  for  Submarine  Shiphandling  and  Piloting  (VESUB)  team  was  assembled  to 
harness  the  knowledge  and  skills  necessary  to:  (1)  fully  understand  the  shiphandling  task  that 
was  to  be  trained;  (2)  support  the  modeling  and  programming  necessary  to  create  and  operate 
within  the  virtual  environment;  and  (3)  design  and  implement  an  effective  instructional  design 
that  would  ensure  task  related  knowledge  transfer. 


OBJECTIVE 

This  is  the  third  in  a  series  of  reports  to  document  the  VESUB  project.  This  report 
supplements  the  previous  publications  in  the  series,  NAWCTSD  Technical  Reports  97-013  and 
98-003,  which  documented  the  usability  analysis  for  the  VESUB  Instructor/Operator  Station  and 
the  VESUB  TEE,  respectively.  The  objective  of  this  report  is  to  provide  a  chronology  of  project 
events  and  an  assemblage  of  critical  technical  and  process  issues  that  played  a  significant  role  in 
the  development  of  the  VESUB  system,  and  which  offer  an  insight  into  project  development  for 
this  and  other  training  systems  that  employ  state-of-the-art  technologies. 


ORGANIZATION  OF  THE  REPORT 

The  Background  section  provides:  1)  a  brief  description  of  the  submarine  shiphandling  task 
and  the  training  requirement  for  the  VESUB  training  system;  2)  an  explanation  of  why 
submarine  shiphandling  was  chosen  as  the  technology  demonstration  task;  and  3)  a  chronology 
of  the  VESUB  project,  which  includes  an  overview  of  the  planned  and  executed  stages.  The 
Simulation  and  Training  Issues  Section  describes  both  programmatic  and  technical  issues 
identified  in  the  VESUB  project.  In  describing  these  issues  it  is  hoped  that  the  lessons  may  be 
applied  to  other  projects.  The  importance  of  team  communications  to  project  performance, 
especially  when  members  are  not  co-located,  and  the  impact  of  good  and  poor  communications 
are  discussed.  The  use  of  subject  matter  experts  (SMEs),  both  internal  and  external  to  the 
Government,  is  reviewed  and  evaluated.  Finally,  Conclusions  and  Recommendations  are 
provided  to  help  in  the  development  of  the  operational  VESUB  training  system  (VESUB  2000) 
and  other  VR-based  training  systems. 
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THE  VIRTUAL  ENVIRONMENT  FOR  SUBMARINE  SHIPHANDLING  AND 

PILOTING  (VESUB)  TRAINING  TECHNOLOGY  DEMONSTRATION  PROJECT 

BACKGROUND 

The  objective  of  the  VESUB  project  was  threefold:  (1)  to  develop,  demonstrate,  and  evaluate 
the  training  potential  of  a  stand-alone  VR-based  system  for  submarine  shiphandling  training;  (2) 
to  determine  if  this  system  could  be  integrated  with  existing  Submarine  Piloting  and  Navigation 
(SPAN)  training  simulators;  and  (3)  to  determine  the  viability  of  VR  technology  as  a  training 
tool.  VESUB  proceeded  as  a  multiphased  program,  consisting  of:  (1)  requirements 
determination;  (2)  formative  evaluations;  (3)  training  effectiveness  evaluation  (TEE);  and  (4) 
transition  of  R&D  results  to  support  the  acquisition  of  operational  systems  (VESUB  2000). 

The  Submarine  Officer  of  the  Deck  (OOD)  mans  the  bridge  with  the  assistance  of  a  lookout 
and,  many  times,  a  Junior  Officer  of  the  Deck  (JOOD).  His  responsibilities  include  all  aspects  of 
ship’s  evolutions,  and  the  safe  navigation  and  piloting  of  the  ship.  In  his  shiphandling  tasks,  he 
must  demonstrate  an  understanding  of:  the  environment;  limitations  of  channels  and  harbors; 
available  navigational  aids;  contact  management;  and  rales  of  the  nautical  road. 

The  placement  of  the  OOD,  literally  on  the  top  of  the  submarine,  with  a  360-degree  view  of 
his  surroundings,  provided  an  excellent  setting  for  a  VE.  In  addition  to  this  visual  plane,  the 
Submarine  OOD  manages  a  complex  task  in  the  execution  of  his  responsibilities.  Though 
isolated  on  the  ship’s  bridge,  he  monitors  and  observes  the  environment,  and  directs  the  actions 
necessary  to  CONN  (maneuver)  the  submarine  through  harbor  and  channel.  He  communicates 
his  desires  through  voice  commands  over  electronic  circuits  and  receives  both  voice  and  visual 
confirmations  of  his  orders.  Because  of  the  important  visual  component  of  the  task  and  the 
Navy’s  need  for  a  simulation  capability,  the  surfaced  submarine  shiphandling  task  was 
determined  to  be  a  prime  candidate  for  examination  of  the  effectiveness  of  VR  systems  for 
training  applications. 


VESUB  CHRONOLOGY 


In  May  of  1994,  a  Problem  Description  and  Needs  Justification  (PDNJ)  was  submitted  to  the 
Manpower,  Personnel,  and  Training  (MPT)  6.3  Research  and  Development  Program  by  the 
Naval  Air  Warfare  Center  Training  Systems  Division  (NAWCTSD),  entitled  "Virtual 
Environment  for  Submarine  Piloting  Training."  In  July  of  1994,  a  Technical  Development  Plan 
was  requested  on  this  topic  from  the  Advisor  for  Research  Management  at  the  Bureau  of  Naval 
Personnel.  The  Virtual  Environment  for  Submarine  Shiphandling  and  Piloting  Training 
(VESUB)  project  began  in  October  of  1994. 
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Contractual  Support 

In  June  of  1995  a  contract  was  established  with  BBN  Systems  and  Technologies  to  assist  in 
the  determination  of  VESUB  requirements.  This  task  was  accomplished  through  questionnaires 
and  interviews  with  fleet  SMEs  and  by  using  a  feasibility  demonstration  system  developed  under 
the  Office  of  Naval  Research-funded  6.2  Virtual  Environment  Training  Technology  (VETT) 
project.  This  system  was  used  as  a  knowledge  elicitation  tool  to  obtain  detailed  requirements 
inputs  from  the  SMEs.  Although  it  only  included  a  simplified  harbor  scene  and  submarine 
model,  which  was  viewed  through  a  low  resolution  HMD,  this  system  afforded  the  SMEs  a 
chance  to  experience  a  virtual  environment.  VESUB  requirements  were  documented  in  a 
NAWCTSD  Special  Report  (Tenney,  Briscoe,  Pew,  Bradley,  Seamon,  &  Hays,  1996). 

In  March  of  1996  contracts  were  established  with  Nichols  Advanced  Marine  Engineering 
(AME)  and  Sonalysts,  Inc.  The  software  and  hardware  integration  for  VESUB  was  executed  by 
AME.  To  save  time  and  money,  VESUB  was  developed  by  leveraging  AME’s  Virtual  Ship 
application,  a  commercial  product  that  has  been  used  for  several  years  to  train  surface 
shiphandling  tasks  in  a  rear  projection  theater  environment.  SMEs  were  drawn  initially  from 
fleet  training  and  operational  commands,  however,  to  meet  the  demands  of  daily  development, 
Sonalysts  was  placed  under  contract  by  NAWCTSD  to  provide  SME  support  focused  on 
submarine  piloting  and  navigation.  This  included  the  accomplishment  of  periodic  system 
reviews  to  evaluate  system  improvements  and  software  deliveries  from  the  developer.  Sonalysts 
also  collaborated  in  identification  of  the  critical  learning  elements  that  would  be  used  to  measure 
trainee  performance  and  in  conducting  the  TEE. 


Perceptual  and  Cognitive  Task  Analysis 

A  perceptual  and  cognitive  task  analysis  was  conducted  using  "Seaman's  Eye"  as  a  means  to 
focus  the  effort.  "Seaman's  Eye"  is  a  term  used  by  experienced  ship  handlers  to  describe  the 
collective  skills  required  by  the  OOD  during  surface  evolutions.  Through  interactions  with 
expert  consultants,  like  submarine  commanding  officers  and  harbor  pilots,  the  team  derived  the 
following  definition  of  “Seaman’s  Eye”  to  guide  the  perceptual  and  cognitive  analysis. 

The  total  situation  awareness  of  the  shiphandling  environment 
and  the  ability  to  safely  maneuver  the  vessel  in  all  conditions. 

Iterative  probing  of  SMEs,  using  focused  group  discussions  at  Navy  training  facilities  and  in 
the  NAWCTSD  laboratory,  detailed  eight  perceptual  and  twelve  cognitive  components  that  make 
up  this  complex  concept  (see  Table  1).  These  components  were  used  to  make  hardware, 
software,  and  instructional  decisions  during  the  formative  evaluation  and  later  phases  of  the 
project  (Hays,  Vincenzi,  Seamon,  and  Bradley,  1998). 
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Table  1 

Components  of  “Seaman’s  Eye” 

PERCEPTUAL  COMPONENTS 

IP.  Locating  and  Identifying  Navigation  Aids _ 

2P.  Judging  Distance _ 

3P.  Identifying  the  Start  and  Completion  of  Turns _ 

4P.  Locating,  Identifying,  and  Avoiding  Obstacles _ 

5P.  Sense  of  Ship’s  Responsiveness  _ 

6P.  Recognizing  Environmental  Conditions _ 

7P.  Recognizing  Equipment  Failures  _ 

_ COGNITIVE  COMPONENTS 

1C.  Understanding  the  Relationship  of  Visual  Cues  to  their  Representations  on 

Charts _ _ _ 

2C.  Understanding  Relative  Size  and  Height/Range  Relationships,  and 

_ Angle  on  the  Bow  (AOB) _ 

3C.  Understanding  Advance  and  Transfer  _ 

4C.  Understanding  the  Effects  of  Tides,  Currents,  Wind,  and  Seas _ 

5C.  Understanding  Rules  of  the  Road _ 

6C.  Understanding  Relative  Motion  (Direction  and  Speed) _ 

7C.  Understanding  Methods  to  Differentiate  and  Prioritize  Traffic  Contacts 

8C.  Understanding  Ship’s  Operation  Under  Harbor  Directives _ 

9C.  Understanding  Methods  to  Deal  with  Uncooperative  Traffic _ 

10C.  Understanding  Correct  Operation  of  Ship’s  Systems _ 

1 1C.  Understanding  When  and  How  to  Take  Corrective  Actions _ 

12C.  Understanding  Effective  Communication  Procedures 


Formative  Evaluations 

The  formative  evaluation  phase  was  conducted  in  the  laboratory  at  NAWCTSD.  Whenever 
AME  delivered  an  improved  iteration  of  the  VESUB  software,  it  was  evaluated  against  the 
functional  requirements  by  the  VESUB  research  team.  Data  for  the  formative  evaluations  were 
also  collected  from  eleven  fleet  and  school  SMEs  and  nine  Navy  reservists  with  shiphandling 
experience  following  extensive  exposure  to  VESUB.  As  soon  as  the  formative  data  were 
collected,  the  results  were  provided  to  AME  to  guide  system  improvements.  The  formative 
evaluations  focused  on  both  the  functionality  of  the  trainee  interface  (e.g.,  the  fidelity  of  objects 
in  the  visual  scene,  the  functionality  of  the  voice  recognition  system,  and  the  hydrodynamics  of 
the  ship  models)  and  the  usability  of  the  Instructor/Operator  Station  (IOS). 
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Training  Effectiveness  Evaluation  (TEE) 


TEE  Approach.  The  TEE  for  the  VESUB  technology  demonstration  system  was  conducted 
at  the  Submarine  Training  Facility  in  Norfolk,  Virginia  and  the  Naval  Submarine  School  in 
Groton,  Connecticut  during  the  winter  and  spring  of  1998.  The  TEE  used  Navy  trainees  with 
various  levels  of  shiphandling  experience  (novice  to  expert)  to  determine  the  effectiveness  of  the 
VESUB  system  and  to  help  determine  how  the  technology  can  be  integrated  into  Navy  training. 

At  each  site,  the  VESUB  system  was  set  up  in  a  room  where  the  TEE  could  be  conducted 
without  interfering  with  ongoing  training. 

Forty-one  participants  experienced  three  VESUB  scenarios.  The  first,  was  an  orientation  * 

scenario  to  allow  them  to  experience  and  practice  system  functionality,  the  second,  was  a  training 
scenario  which  targeted  several  specific  shiphandling  tasks  (derived  from  the  perceptual  and  * 

cognitive  task  analysis),  and  the  third,  was  a  comparable  scenario  to  test  the  trainees’ 
improvement  on  these  shiphandling  skills.  Prior  to  the  first  scenario,  demographic  data  were 
collected  and  a  comfort  questionnaire  was  administered  to  assess  the  participants’  physical 
condition.  After  completion  of  each  scenario,  the  comfort  questionnaire  was  again  administered 
to  assess  any  physical  changes  experienced  by  the  participants.  Finally,  each  participant 
provided  comments  on  the  VESUB  system  and  recommendations  for  its  use  and  improvement. 


TEE  Results.  Data  were  collected  on  fifteen  shiphandling  variables  grouped  into  seven  skill 
categories.  A  mixed  factorial  analysis  of  variance  (ANOVA)  design,  with  experience  as  the 
between-subjects  variable  and  scenario  session  (training  and  testing)  as  the  within  subjects 
variable,  found  significant  learning  (skill  improvements)  for  all  experience  levels  (0  to  14  years) 
on  eleven  of  the  fifteen  variables.  For  example,  trainees  improved: 


•  39%  in  checking  range  markers 

•  33%  in  visually  checking  the  rudder 

•  13%  in  issuing  correct  turning  commands 

•  57%  in  contact  management  skills 

•  44%  in  reaction  time  during  a  man  overboard  (MOB)  event 

•  29%  in  using  correct  commands  during  the  MOB  event 

•  40%  in  using  correct  commands  during  a  yellow  sounding  event 

No  major  simulator  side  effects  problems  were  found.  Less  than  5%  of  the  trainees 
experienced  side  effects  that  were  detrimental  to  training,  even  though  trainees  averaged  almost 
two  hours  in  the  head-mounted  display  (HMD).  Details  on  these  and  other  TEE  data  are 
presented  in  Hays,  et  al.  (1998). 


» 
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SIMULATION  AND  TRAINING  ISSUES 


Over  the  course  of  the  VESUB  project,  team  members  learned  a  variety  of  lessons  about  the 
problems  of  developing  a  complex  state-of-the-art  VE  training  system.  Though  resources  often 
limited  project  response  to  these  lessons,  their  importance  to  VESUB  and  its  follow-on  training 
system,  as  well  as  other  training  systems  that  employ  similar  processes,  could  prove  to  be 
significant. 

These  lessons  included  a  wide  range  of  issues,  from  hardware  and  software  configuration 
management  and  legacy  system  interfacing,  to  speech  and  visual  system  integration.  Other  key 
areas  included  task-specific  detailing  for  accuracy  and  training  effectiveness,  as  well  as,  project 
management  and  control  issues  that  are  not  often  considered  during  project  planning.  Discussing 
these  lessons  as  they  relate  to  the  VESUB  functionality  requirements  established  by  the  team 
should  provide  a  better  level  of  understanding  of  the  nature  and  difficulty  faced  by  developers  in 
the  VE  arena. 


SYSTEM  HARDWARE  AND  SOFTWARE  IMPLEMENTATION 
Computer  Platforms 

The  VESUB  technology  demonstration  system  consisted  of  a  Silicon  Graphics  (SGI)  Onyx 
Infinite  Reality  (IR)  and  two  desktop  SGI  Indy  computers.  The  SGI  Onyx  was  selected  as  die 
image  generator  for  this  project  because  it  was  the  only  system  available  with  full  hardware  anti¬ 
aliasing  and  the  ability  to  rapidly  construct  polygons  for  the  visual  scene  at  the  high  refresh  rate 
required  to  meet  the  VESUB  task  requirements. 
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Figure  1  shows  the  VESUB  system  in  the  NAWCTSD  laboratory  during  the  formative 
evaluations.  Two  instructors  are  seated  at  the  IOS  while  a  trainee,  wearing  the  HMD,  issues 
voice  commands.  The  two  SGI  Indy  computers  were  employed  as  the  IOS  and  to  support 
applications  that  were  not  compatible  with  the  operating  system  software  running  on  the  Onyx. 
The  voice  recognition  software  ran  on  one  unit  while  the  environmental  sound  software  ran  on 
the  other.  This  layering  of  software  may  not  have  been  optimum.  However,  it  was  considered 
acceptable  for  use  in  a  technology  demonstration.  Hosting  all  processes  on  a  single  platform 
would  have  reduced  interface  issues  and  configuration  concerns  had  all  the  software  been 
compatible. 


Visual  System 

The  HMD  initially  used  for  the  feasibility  demonstration  system  and  the  initial  stage  of  the 
VESUB  project  was  a  Virtual  Research  VR4.  This  HMD,  which  used  a  liquid  crystal  display 
with  relatively  low  resolution,  did  not  sufficiently  support  the  detailed  rendering  of  the  modeled 
environment  for  the  shiphandling  task.  Specifically,  the  ability  to  see  objects  at  distances, 
effective  contrast  and  shading,  and  the  ability  to  read  details  on  displays  and  charts  required  a 
higher  resolution  display. 

An  n- Vision  high  resolution  Datavisor  HMD  was  acquired  to  improve  the  usability  of  VESUB 
tools  and  resulted  in  significant  improvements  in  trainee  performance.  Additional  improvements 
are  still  required  to  effectively  display  many  of  the  visual  cues  associated  with  the  VE,  including 
the  ability  to  accurately  discern  currents,  tide  rips,  details  of  lights  and  shapes  (e.g.,  types,  colors, 
shapes)  and  an  enhanced  field  of  view  in  both  horizontal  and  vertical  planes.  Key  improvements 
to  HMD  usability  would  result  from  improved  weight,  comfort,  field  of  view,  balance,  and 
reduction  in  ambient  light  from  external  sources. 


Software 


The  primary  software  used  in  the  VESUB  system  is  a  modified  version  of  Virtual  Ship,  a 
commercial  product  licensed  from  AME.  One  of  the  functions  of  Virtual  Ship  was  to  integrate 
and  work  with  the  several  layers  of  software  that  provide  the  functionality  required  by  VESUB. 
This  software  is  the  engine  that  provides  interface  and  functionality  for  AME’s  established 
shiphandling  trainers  for  commercial  and  military  surface  vessels.  A  complete  list  of  VESUB 
software  is  provided  in  Appendix  A.  The  modified  version  of  Virtual  Ship  employed  in  VESUB 
had  to  simultaneously  operate  with  several  revisions  of  the  SGI  IRIX  operating  system.  This 
was  due  to  incompatibilities  experienced  between  required  utility  applications  necessary  for 
VESUB’ s  operation.  These  incompatibilities  were  the  primary  reason  that  all  processes  were  not 
loaded  and  running  on  the  Onyx  computer. 

The  complexity  of  the  Virtual  Ship  processes  caused  occasional  problems,  as  did  the  use  of 
“patches”  within  the  operating  system.  These  faults  generally  manifested  themselves  as  files  not 
being  readily  found  or  the  incorrect  application  of  tools,  which  resulted  in  system  lock-up  or 
faulty  operations.  Operational  systems  may  be  better  served  with  a  system  that  operates  more 
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seamlessly  and  which  is  less  layered  in  design.  For  the  most  part,  however,  the  Virtual  Ship 
structure  provided  the  necessary  functionality  for  the  VESUB  technology  demonstration. 

The  proprietary  nature  of  the  Virtual  Ship  program  further  complicated  the  VESUB  process  as 
programmers  at  NAWCTSD  were  unable  to  access  source  code  to  make  changes  that  would 
improve  the  system,  even  after  the  contracted  period  of  performance.  An  off-the-shelf 
application  or  an  open  system  architecture  would  afford  the  Navy  better  control  of  modifications 
such  as  the  addition  of  new  ship  models  or  enhanced  functionality. 


PROGRAMMATIC  ISSUES 
Project  Management  Process 

The  VESUB  project  was  planned  and  executed  by  a  team  whose  members  were  located  at 
different  geographic  sites.  This  proved  to  be  a  critical  issue  in  the  performance  of  the  VESUB 
system.  The  project  team  had  to  simultaneously  address  the  technical  issues  related  to 
developing  a  VR  training  system  (e.g.,  identifying  system  requirements  to  support  acceptable 
refresh  rates)  and  accuracy  of  the  task  related  elements  of  submarine  shiphandling  (e.g.,  accurate 
characteristics  of  ship  performance).  AME,  Sonalysts,  and  NAWCTSD  team  members 
communicated  with  each  other  via  e-mail  and  telephone,  as  well  as,  face-to-face  interactions  in 
the  lab.  Engineers  at  AME  and  NAWCTSD  established  methods  for  transferring  software 
revisions  and  for  working  together  to  load  and  execute  programs.  Additionally,  the  team 
conducted  a  biweekly  telephone  conference  to  ensure  an  open  communications  environment. 

This  communications  cycle  was  accompanied  by  an  action  list  that  established  and  tracked 
issues.  The  list  and  its  content  were  simple,  and  actions  were  distributed  to  appropriate  team 
members.  Subsequently,  the  action  list  was  updated  through  meetings  and  telephone 
conferences.  Prioritization  was  also  an  issue.  The  government  established  priority  for  most  of 
the  action  items,  but  they  were  not  always  the  focus  of  the  developers.  Deadlines  shifted, 
milestones  passed,  and  deliveries  were  delayed.  Sometimes  this  was  because  related  work  had  to 
be  accomplished  as  a  block.  However,  too  often  scheduling  was  accomplished  without  apparent 
regard  to  the  established  priority.  A  more  formal  action/task  tracking  procedure  is  essential  for 
such  complex  efforts  as  VESUB. 

The  goal  of  the  formative  evaluations  was  to  allow  SMEs  to  use  and  evaluate  the  VESUB 
system  in  the  NAWCTSD  lab  and  to  provide  direct  feedback  to  the  development  team,  who 
would  in-tum  modify  the  system  based  on  this  expert  commentary.  In  general,  this  process 
worked  well.  However,  developers  not  knowing  when  to  ask  questions  of  the  SMEs,  would 
move  ahead  with  their  programming  believing  that  they  were  on  the  right  development  track. 
Later  they  discovered  their  programs  were  incorrect  and  needed  to  be  changed.  These 
modifications  caused  delays,  wasted  resources,  and  created  internal  team  conflicts  that  degraded 
the  development  process. 


21 


Technical  Report  1999-002 


Configuration  Management 

The  desired  functionality  of  the  VESUB  training  system  called  for  upgrades  in  all  areas  of 
technology.  The  VE  technology  demonstration  required  AME  and  NAWCTSD  to  set  up 
duplicate  systems  with  what  was  planned  to  be  identical  hardware  and  software  suites. 
NAWCTSD  elected  to  use  the  SGI  hardware  from  previous  research  efforts  as  the  foundation 
computer  for  VESUB.  This  required  the  team  to  schedule  several  revisions  and  upgrades  that 
would  bring  this  machine  up  to  the  demands  of  the  project. 

The  second  SGI  computer  (SGI  Onyx  2)  was  purchased  for  use  at  AME’s  site.  This 
contracted  purchase  yielded  the  exact  configuration  requested  by  the  technical  demands  of  the 
project.  The  dual  path  taken  here  to  secure  the  hardware  proved  to  be  the  source  of  configuration 
problems  that  lasted  throughout  the  project’s  life.  The  configuration  management  issues  for  the 
hardware  hinged  around  the  real  differences  between  upgraded  computers  and  new  platforms  that 
were  manufactured  to  the  higher  standard  from  the  frame  up.  The  laboratory  hardware  was  not 
effectively  upgraded  to  duplicate  the  capabilities  of  the  newer  model,  which  led  to  difficulties  in 
the  governments  ability  to  evaluate  software  features.  This  configuration  mismatch  resulted  in 
the  two  systems  performing  differently  when  running  identical  software  revisions. 

System  developers  and  modeling/graphics  specialists  at  AME  operated  from  several 
workstations  and  were  linked  to  the  Onyx  through  a  network.  This  offered  valuable  development 
advantages,  but  also  allowed  these  team  members  to  simultaneously  host  other  projects  on  the 
Onyx.  The  use  of  a  network  structure,  as  well  as  the  sharing  of  the  platform  with  other  projects, 
changed  the  operating  characteristics  of  the  system  and  resulted  in  variations  of  software 
performance  between  this  system  and  the  non-networked  Onyx  at  NAWCTSD.  The  system  was 
not  tested  in  stand-alone  mode  before  it  was  shipped  to  the  TEE  sites.  The  lack  of  stand  alone 
operation  and  testing  resulted  in  significant  operational  inconsistencies  which  were  discovered 
during  the  first  TEE  (not  enough  memory).  In  fact,  system  configuration  and  controls  were  at 
fault  and  corrective  actions  had  to  be  identified  and  accomplished  at  the  TEE  site.  A  better 
process  of  software  quality  control  and  configuration  monitoring  to  ensure  that  all  elements  and 
modules  developed  will  run  equally  well  on  all  associated  training  system  platforms. 

Software  management  issues  resulted  from  the  complex  integration  called  for  by  the  Virtual 
Ship  process.  There  were  incompatibilities  that  had  to  be  addressed  and  which  drove  design 
considerations  for  the  project.  For  example,  HARK  the  voice  recognition  software,  was  a 
carryover  from  the  feasibility  demonstration  system.  The  developer  did  not  evaluate  other 
systems  or  weigh  the  impact  of  this  selection  in  the  broader  context  of  VESUB ’s  operability. 
HARK’s  developers  had  elected  to  suspend  its  development  for  SGI  platforms  which  meant  that 
it  would  only  work  on  earlier  IRIX  operating  systems.  The  decision  to  use  Hark  forced  the 
design  to  include  an  additional  SGI  Indy  station  to  accommodate  this  application. 

Software  licenses  also  needed  to  be  managed.  On  occasion,  erroneous  license  expirations 
caused  the  system  to  lock  out.  Project  managers  need  to  secure  open  ended  licenses  for  all 
software  applications  that  will  be  incorporated  into  their  system,  and  software  management  needs 
to  be  initiated  early-on  to  eliminate  this  problem. 
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In  Process  Reviews  (IPRI  and  Other  Meetings 

Any  complex  project  requires  close  liaison  between  all  team-members.  For  VESUB,  it  was 
hoped  that  communications  could  be  informal  wherever  possible.  It  was  felt  that  project 
resources  could  best  be  used  on  development  and  integration,  rather  than  on  costly  travel  for 
team  meetings.  This  approach  assumed,  however,  that  the  use  of  telephone  conferences  and 
action  lists  would  result  in  effective  team  performance.  These  tools  proved  to  be  less  effective 
than  anticipated. 

One  example  of  a  problem  that  might  have  been  corrected  in  a  face-to-face  meeting  involved 
the  focus  of  project  development.  The  VESUB  system  was  based  on  an  existing  AME  product 
and  the  developers  were  locked  into  this  system  and  its  capabilities.  This  tended  to  influence  the 
development  path  selected,  its  design,  and  even  its  appearance  on  screen.  While  AME’s  project 
leader  committed  to  addressing  submarine  related  aspects  by  making  required  changes  to  the 
Virtual  Ship  product,  changes  were  slow  in  coming  and  many  were  never  accomplished. 

Potentially,  more  face-to-face  IPRs  and  other  meetings  could  focus  team  attention  on  the 
objectives  and  status  of  the  project  and  allow  each  team  member  to  be  heard.  Furthermore,  they 
offer  the  Principal  Investigator  a  method  to  formally  establish  the  development  path  that  would 
optimize  resources  for  overall  project  success. 


Impact  of  Demos  on  Development 

The  objective  of  the  VESUB  project  was  to  develop  an  effective,  user-friendly  training 
demonstration  that  could  support  a  real  fleet  need  and  transition  into  a  valuable  training  system 
for  the  Navy.  Development  time  was  often  at  a  premium,  especially  as  the  process  matured 
towards  the  scheduled  TEEs.  VESUB,  however,  rapidly  became  one  of  the  most  popular 
systems  to  show  on  tours  of  NAWCTSD.  Its  use  of  advanced  technologies  and  the  attractive 
nature  of  the  VR  approach  made  it  the  preferred  demonstration  tool  to  highlight  NAWCTSD’s 
skills  and  capabilities.  VESUB ’s  celebrity  status  had  a  decidedly  negative  impact  on  the  ability 
of  the  team  to  focus  and  accomplish  project  goals.  VESUB  researchers  often  conducted  daily 
demonstrations,  some  requiring  several  hours  of  preparation  and  execution,  which  had  a  real 
impact  on  time  and  resource  management  for  the  project. 


Shared  System  Resources 

VESUB  was  one  of  the  most  detailed  and  complex  training  systems  yet  undertaken  at 
NAWCTSD.  It  required  several  levels  of  software  applications,  user  interfaces  using  two  I/O 
paths,  detailed  modeling  and  scene  rendering,  and  complex  database  management.  The 
complexity  of  VESUB  was  clear,  yet  for  more  than  a  year  other  systems  were  co-hosted  on  the 
laboratory  Onyx.  This  detrimentally  affected  schedules  and  operations.  Team  members  had  to 
timeshare  with  these  other  projects,  and  demonstrations  of  unrelated  work  often  required  the 
VESUB  team  to  reschedule  their  efforts.  There  were  also  indications  that  this  co-hosting 
impacted  system  operations  by  slowing  processing  during  VESUB  evolutions.  Because 
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processing  and  refresh  rate  are  considered  key  elements  to  the  visual  performance  in  the  VE 
presentation,  the  impact  on  slower  performance  was  troubling  until  other  project  software  was 
removed. 


Legacy  Software  Use  in  New  System  Development 

VESUB  was  based  on  legacy  software.  This  baseline  system,  Virtual  Ship,  provided  a  starting 
point  for  the  VESUB  technology  demonstration  that  included  some,  but  not  all,  of  the 
functionality  called  for  to  meet  the  submarine  shiphandling  task.  While  the  positive  aspects  of 
leveraging  this  application  may  outweigh  the  negative  ones,  it  is  important  to  note  that  several 
deficiencies  resulted  from  this  approach.  An  existing  technology  tool-set  was  employed  that  had 
not  evolved  over  time.  With  the  explosive  growth  of  technology,  this  may  have  artificially 
constrained  VESUB  development.  Additionally,  if  the  developer  is  the  originator  of  the  legacy 
system,  they  may  have  a  predetermined  mindset  as  to  how  the  system  should  be  designed. 
Existing  models,  interface  methods,  development  and  scenario  generation  tools  are  already  in 
place  and  the  easiest  path  for  fielding  the  follow-on  project  is  through  the  use  of  these  tools. 

New  approaches  may  be  challenged  and,  because  of  this,  opportunity  for  improvement  or 
enhancement  may  be  lost. 

Other  issues  related  to  streamlining,  improved  modeling,  image  generation,  interface  design, 
and  application  management  offer  other  arguments  against  using  legacy  systems.  This  conflict 
will  continue,  however,  because  the  employment  of  these  systems  often  reduces  costs,  saves 
time,  and  offers  a  list  of  developmental  efficiencies  as  well.  Usability,  functionality, 
applicability  and  openness  of  design,  as  well  as  projected  longevity,  should  all  be  considered 
when  evaluating  the  use  of  a  legacy  system  as  a  baseline  for  an  emerging  project. 


VESUB  REQUIRED  FUNCTIONALITY 

The  VESUB  technology  demonstration  system  broke  new  ground  in  the  field  of  VE  training 
systems  development.  Several  technologies  were  incorporated  to  provide  the  functionality 
necessary  to  support  the  project  goals.  A  wide  variety  of  lessons  were  learned  during  this  project 
which  will  help  to  support  the  development  of  VE  training  systems.  VESUB  required 
functionality  was  initially  identified  in  Tenney,  et  al.  (1996).  These  requirements  were  later 
detailed  by  the  VESUB  team  and  incorporated  into  project  planning.  Table  2  is  a  status  list  of 
these  and  other  requirements.  The  following  discussion  provides  details  on  the  status  of  these 
requirements. 
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Table  2 


Status  of  VESUB  Required  Functionality 


Requirement 


Completed 


Not  Completed 


SPAN  Interface 


Submarine  Dynamics  (6881  &  726): 

•  Pitch,  Roll,  &  Heave - 

•  Advance  &  Transfer - 

•  Acceleration/Deceleration - 

•  Turns  per  Knot - 

•  Collision  Detection - 


Currents: 

•  Effects  on  Own  Ship - 

•  Effects  on  Contacts - 

•  Effects  on  Buoys - 

•  Appearance - 

•  Dynamic  (Time/Date) - 


Wind: 

•  Effects  on  Own  Ship - 

•  Effects  on  Contacts - 

•  Effects  on  Buoys - 

•  Appearance - 


Own  Ship: 

•  360  degree  View - 

•  Binocular  View - 

•  Topside  Areas: 

Bow - 

Bow  Wave - 

Sail - 

-  Navigation/Anchor  Lights - 

-  Periscopes  &  Masts - 

-  Rudder - 

-  Stem  Wake - 

•  Bridge  Area: 

-  Bridge  Suitcase - 

•  Windscreen - 

-  Compass - 

-  Chart  Book  (dynamic/digital)  — 

-  Course  Card - 

-  Maneuvering  board - 

-  Other  Bridge  Equipment - 


Contacts: 

•  Appearance  (fidelity) - 

•  Navigation/Anchor  Lights - 

•  Hydrodynamic  Performance - 

•  Preprogrammed/Instructor  Control 


Navigation  Aids: 

•  Include  All  Necessary - 

•  Appearance  (e.  g.,  lights) - 

•  Effects  of  Currents - 

•  Position  Adjustment - 


XX  \X  \XX  XX  \x  XXX  \xx 
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Table  2  (Continued) 


Environment: 

Time  of  Day  (24  hrs.)  ■ 

Sun - - - 

Moon . — 


*  Visibility  Effects  (Adjustable/Dynamic)  • 

*  Fog - 

*  Rain - 

*  Sleet/Snow - 

►  Haze - 

» Clouds - 

►  Wind - 

►  Curved  Earth - 


Water  Surface: 

•  Sea  State - 

•  Wind  Effects  ■ 


•  Movement  of  the  Ship - 

•  Depth  of  the  channel  (e.  g.  ,  sandbars)  - 

•  Surf  Zone - 


Harbor  Model: 

•  Consistent  with  Chart  - 

•  Tidal  Change  Indicators  - 


1  Bell  &  Horn  Buoys  - 

•  Wind  Noise  ■ 

►  Bow  Wave  /  Sea  Noise  - 

►  Automatic  Contact  Sounds  - 

Speech  Recognition: 

•  Speaker  Independence - 

•  All  Interior  Communication  Phrases  • 

•  Harbor-Specific  Terms - 


Speech  Synthesis: 

•  Autonomous  Agents  (Navigator,  Helmsman, 

Contact  Coordinator,  Etc) - 

•  Correct  Repeat-back  Phrases - 

•  Correct  Timing  of  Repeat-backs  — 


Single  Large  Screen  Display  - 


X 

X 

X 


X 

X 


X 

X 

X 


X 

X 


X 

X 

X 
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SPAN  Interface 


The  initial  VESUB  project  plan  called  for  linking  VESUB  with  the  existing  Submarine 
Piloting  and  Navigation  (SPAN)  trainers  to  incorporate  an  OOD  into  this  training  process. 

SPAN,  a  proprietary  training  system  developed  by  Evans  and  Sutherland  (E&S)  employs 
imaging  and  computing  systems  that  are  no  longer  readily  available. 

The  interface  plan  was  to  drive  the  VESUB  system  with  positional  data  and  contact 
information  provided  by  SPAN.  This  would  allow  the  VESUB  image  generator  to  create  the 
visual  scene  required  to  match  SPAN  images.  Because  the  participants  would  not  be  viewing  the 
same  data,  the  models  did  not  need  to  be  identical,  only  similar.  Own  ship  and  contact  positions, 
and  geographic  scenes,  however,  needed  to  be  closely  aligned,  as  the  OOD  would  be  making 
decisions  based  on  these  elements.  Contact  type  and  color  could  be  matched  during  scenario 
construction,  and  other  issues  could  be  dealt  with  from  within  VESUB. 

Hardware  inspections  of  SPAN  were  conducted  and  maintenance  connectors  were  identified 
that  would  provide  VESUB  access  to  SPAN  system  data.  Consideration  was  also  given  to 
creating  a  Y-connector  that  would  allow  VESUB  to  tap-off  of  existing  data  transmission  lines 
between  the  SPAN  components.  A  data  stream  was  tapped  and  SPAN  data  were  recorded  that 
potentially  contained  the  appropriate  information  for  creating  a  parallel  simulation  between 
VESUB  and  SPAN.  No  further  action  was  taken  on  this  aspect  of  the  project  because  it  was 
recognized  that  the  costs  of  producing  this  hybrid  system  for  the  VESUB  technology 
demonstration,  beyond  capturing  the  data,  exceeded  the  available  VESUB  resources. 


Simulation  Requirements 

Several  key  requirements  were  identified  as  necessary  elements  for  a  successful  virtual 
environment.  Many  of  these  were  fully  developed.  Some  were  only  partially  completed,  while 
others  were  not  developed  at  all. 

Submarine  Dynamics.  Accurate  simulation  of  the  baseline  model(s)  is  essential  for  the 
participants  to  accept  that  they  are  operating  within  a  realistic  virtual  world.  VESUB ’s  two 
submarines  demonstrated  that  multiple  models  could  be  built  to  support  training  requirements 
but  the  associated  hydrodynamics  were  not  fully  and  accurately  implemented.  This  resulted  in 
inaccurate  reactions  to  passing  contacts  and  those  working  along  side,  which  translated  to  errors 
in  pitch,  roll,  and  heave.  This  indicated  the  need  more  accurate  hydrodynamic  interaction 
elements. 

Modeling  of  a  ship’s  progress  through  water,  or  the  effects  known  as  advance  and  transfer 
(see  Figure  2),  requires  an  understanding  of  how  the  fluid  body  effects  this  motion.  The  Hydro 
Module  of  the  Virtual  Ship  application  provided  by  AME  accounts  for  this,  either  by  providing 
the  necessary  computations  that  yield  these  effects,  or  by  allowing  specific  ship-class  data  to  be 
entered.  To  demonstrate  the  capability  of  the  system  to  execute  hydrodynamics  effects, 
developers  leveraged  the  existing  surface  ship  models  found  in  the  Virtual  Ship  product  and 
modified  the  turning  characteristics  and  acceleration/deceleration  rates  to  imitate  the 
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performance  of  the  two  submarine  classes  included  in  the  VESUB  system.  This  resulted  in  an 
inconsistent  performance  model  that  lacked  all  the  motion  characteristics  necessary  to  represent 
real  motion  through  the  water. 


Figure  2.  Advance  and  Transfer 


Because  ship  maneuverability  is  one  of  the  primary  training  issues  being  addressed,  accurate 
representation  of  maneuvering  is  important  to  the  successful  employment  of  VE  as  a  training 
delivery  tool,  both  for  VESUB  and  for  other  VE  trainers.  Speed  orders  for  VESUB  were 
received  and  displayed  in  standard  navigation  terms.  These  included  engine  orders  bells  for:  All 
Ahead  1/3, 2/3,  Standard,  Full,  and  Flank  and  All  Back  1/3, 2/3,  Full,  and  Emergency.  Speed 
orders  can  also  be  ordered  incrementally  in  revolutions  per  minute  as  marked  by  the  underwater 
log  or  by  propeller  shaft  RPMs  or  “Turns.” 

Turns  per  knot,  or  TPK,  is  the  ratio  of  shaft  RPMs  to  1  knot  of  ship’s  speed.  A  TPK  of  5 
would  mean  that  5  revolutions  per  minute  would  propel  the  ship  forward  at  a  speed  of  1  nautical 
mile  per  hour.  Ten  RPMs  would  yield  2  knots,  15  RPMs  providing  3  knots  and  so  on.  Because 
these  values  are  often  different  for  each  ship  class,  and  are  key  to  precise  shiphandling,  it  is 
important  that  the  models  be  accurately  represented.  VESUB  did  not  successfully  implement 
this  feature,  specifically  limiting  a  trainees  ability  to  issue  speed  and  engine  orders  in  TPK 
increments.  While  impact  on  the  TEE  was  minimal,  failure  to  execute  this  feature  in  a 
shiphandling  trainer  will  limit  precise  shiphandling  capabilities. 

Collision  detection,  the  ability  to  determine  when  objects  in  the  simulation  make  contact  with 
each  other,  was  considered  a  significant  issue  by  the  VESUB  team.  Early  in  the  design  phase, 
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sufficient  evidence  and  emphasis  were  presented  to  the  developer  to  support  the  need  for  this 
requirement.  This  feature  holds  the  potential  to  enhance  the  immersion  effects  of  the  virtual 
environment  by  providing  realistic  cues  that  demonstrate  the  consequence  of  the  trainee’s 
actions.  This  feature  was  important  for  visible  objects,  but  even  more  important  to  demonstrate 
the  effect  of  contact  with  hidden  objects  (e.g.,  the  channel  bottom). 

Effective  collision  detection  must  recognize  objects  that  have  mass  and  would  impact  the 
passage  of  the  submarine.  These  objects,  both  on  and  in  the  water,  include  the  channel  bottom, 
piers,  buoys,  navigational  aids,  other  vessels  and  waterborne  debris.  The  developer  considered 
this  feature  to  be  a  difficult  challenge  because  it  would  require  the  addition  of  a  layer  of 
instructions  that  would  map  and  track  object  boundaries  continuously  to  achieve  the  required 
detection.  It  would  also  require  a  wide  range  of  detailed  responses  to  collisions  that  would 
demonstrate  the  effects  of  impacting  with  other  objects  of  various  size  and  mass.  This  could 
range  from  a  full  grounding  of  the  VESUB  vessel,  deflection  and  shuddering  caused  by  the 
impact,  sinking  of  other  vessels,  or  damage  to  the  object  or  own  ship’s  control  surfaces  (rudder, 
stem  planes,  or  screw).  Though  collision  detection  was  identified  as  a  key  item  in  VESUB ’s 
functional  requirements,  it  was  not  implemented.  This  critical  feature  needs  to  be  developed  for 
VESUB  2000  and  future  shiphandling  training  systems. 

Currents.  Understanding  the  impact  of  currents  on  your  vessel  and  others,  is  a  critical 
component  of  shiphandling.  These  conditions  change  continuously  and  differentially  impact  the 
task  each  time  that  an  OOD  maneuvers  the  ship.  Harbor  and  channel  current  information  was 
adequately  modeled  for  the  VESUB  technology  demonstration.  A  database  was  constructed  that 
generated  realistic  values,  based  on  historic  tides  and  currents,  for  the  harbors  built  for  the 
VESUB  project  and  file  trainee’s  vessel  responded  appropriately  to  these  programmed  forces. 
These  effects,  however,  failed  to  represent  the  environmental  conditions  fully  because  they  were 
only  applied  to  the  ownship.  Other  vessels,  buoys,  and  debris  positioned  within  the  scenario 
remained  unaffected  by  the  currents. 

Detailed  elements  associated  with  currents  and  tides  that  needed  to  be  modeled  but  were  not 
are: 


tidal  rips 

indicators  of  current  strength 
scarring  around  piers 
canting  of  buoys 
swirling  eddies  at  fixed  objects 
indication  of  the  rise  and  fall  of  tides 

shoaling  indications  associated  with  color,  texture,  and  transparency  of  the  water 

sand  bars 

beaches 

grasses 

buoy  location 
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Although  VESUB  dynamically  simulated  the  changes  associated  with  time  of  day,  longer 
dynamic  changes  (e.g.,  diumal/semi-diumal,  season  of  the  year)  were  not  implemented.  These 
changes  offer  additional  realism  to  the  simulation  as  the  trainee  may  be  in  the  VE  for  an 
extended  period. 

Wind.  The  modeling  of  the  wind  effects,  as  identified  by  Tenney,  et  al.  (1996)  was  not 
completed  in  VESUB.  There  are  only  minimal  wind  effects  present  in  the  VESUB  visual  scene. 
Some  of  the  key  indicators  used  by  the  OOD  to  determine  the  direction  and  force  of  the  wind  are; 
cloud  movement,  sea  surface  effects  such  as  spray  and  white  caps,  swaying  and  blowing  of  fixed 
objects  on  shore  (e.g.,  trees,  bushes,  flags),  wind  blown  direction  of  the  seas,  ownship  flag(s), 
and  increased  noise  levels. 

The  physical  effects  of  wind  on  ownship,  contacts,  buoys,  and  other  objects  were  not 
sufficiently  modeled  to  support  the  shiphandling  task.  The  force  generated  by  the  simulated 
wind  pushed  ownship,  but  this  was  not  proportional  to  the  exposed  surface  area  of  the  vessel,  nor 
did  it  respond  to  the  angle  of  impact.  Similar  to  current,  other  objects  in  the  scenario  were  left 
unaffected  by  the  simulated  forces  of  the  wind.  The  trainee  was  left  to  deal  with  wind  that  set  his 
vessel  left  or  right  of  track,  but  had  no  indicators  (e.g.,  moving  clouds,  waving  flags,  surface 
spray,  canting  of  passing  sailboats)  to  support  his  decision  process.  In  addition,  he  may  have 
falsely  anticipated  the  track  of  other  vessels  operating  without  the  effects  of  wind. 


Visual  Display  Requirements 

System  developers  need  to  understand  that  each  enhancement  added  to  the  visual  display 
exacts  some  price.  Whether  against  a  budget  line,  in  delayed  refresh  rate  or  computational 
resource,  there  will  be  an  impact  that  will  need  to  be  planned  and  accounted  for.  Nevertheless, 
the  following  visual  requirements  justify  additional  development  to  support  the  requirements  of 
the  task. 

Own  Ship/Topside  Areas.  There  are  two  key  concerns  about  the  manner  in  which  VESUB 
represented  the  submarine’s  bow.  The  first  is  related  to  the  visible  shape  of  the  bow,  while  the 
second  has  to  do  with  how  the  bow  shape  affected  the  ship’s  motion  through  the  water.  A 
submarine’s  bow  is  broad,  round  and  bulbous.  From  above  the  water  much  of  the  bow  is 
concealed.  The  greatest  portion  of  it  being  below  the  water  line.  The  waterline  provides  a 
smooth,  concentric  arch  across  the  front  of  the  visible  structure.  The  VESUB  model  portrayed 
the  waterline  as  a  series  of  straight  lines  linked  as  parts  of  an  octagon,  which  was  unrealistic  and 
distracting  to  the  trainee. 

Due  to  this  design,  the  bow  of  the  submarine  slips  through  the  ocean  unlike  any  other  vessel. 
The  rounded  hull  displaces  the  water  and  causes  it  to  build  a  wave  that  moves  over  and  around 
the  submarine  as  it  thrusts  forward.  This  action  forces  the  bow  down,  not  up,  and  in  general  the 
submarine  does  not  ride  the  waves  as  a  conventional  surface  vessel  would.  The  submarine 
hydrodynamics  models  was  leveraged  from  a  surface  ship  model  with  its  traditional  bow  actions, 
which  inaccurately  represented  rise  and  fall  of  the  bow  in  the  visual  scene.  Creating  a  rounded 
bow  and  employing  accurate  submarine  hydrodynamics  are  needed  to  improve  the  accuracy  of 
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the  visual  scene  and  to  provide  the  correct  visual  cues  (e.g.,  shape  and  location  of  the  bow  wake) 
to  the  OOD  as  he  experiences  the  shiphandling  task. 

Because  the  VESUB  submarine  hull  model  was  not  accurate,  the  bow  wave  presentation 
resulted  in  a  less  robust  representation  of  the  wave  than  is  produced  by  either  the  6881  or  726 
class  of  submarine.  In  reality,  the  bow  wave  and  trough  generated  by  the  submarine  hullform 
starts  just  aft  of  the  bow  at  slow  speed.  As  speed  increases,  the  wave  front  and  trough  move  aft, 
drawing  deeply  against  the  hull.  The  wave,  with  its  froth  and  foam,  has  two  distinct  parts  that 
needed  to  be  represented  in  the  VESUB  model.  First,  a  deep  wave  angles  out  as  a  broad  V  that 
moves  sharply  (45  degrees)  away  from  the  ship.  This  is  a  wave-swell  (not  white  water)  that  is 
pronounced  and  distinct  at  speeds  greater  than  8  knots.  White  water  generates,  as  the  second 
part,  from  the  breaking  water  of  the  bow  and  the  related  suction  effects  that  are  at  work.  This 
broad  white  wave  begins  at  the  point  of  break,  located  between  the  bow  and  the  sail,  moving  aft 
and  extending  out  from  this  point  with  point-of-origin  and  force  as  a  function  of  speed.  The 
modeling  of  these  effects  needs  to  be  improved  to  properly  provide  speed  and  sea  state  cues  to 
VESUB  trainees. 

The  size  of  the  wake  generated  by  the  submarine  is  a  function  of  the  bow  wave  and  the 
propeller  generated  scar,  both  create  white  water  and  chop  that  persist  for  an  extended  period  of 
time  and  distance  astern  of  the  submarine.  The  wake  begins  to  spread  out  from  the  ship  starting 
at  the  point  of  bow-wave  break  between  the  bow  and  the  sail.  It  becomes  wide  and  pronounced 
at  speeds  above  8  knots.  At  “All  Ahead  Standard,”  its  width  is  more  than  three  times  that  of  the 
ship,  or  50+  yards  wide,  extending  aft  to  combine  with  the  stem  wake  where  it  persists  for 
several  miles  behind  the  ship. 

The  propulsion  component  of  the  submarine’s  wake,  or  stem  wake,  starts  at  the  propeller.  At 
slow  speeds,  it  chums  water  just  aft  of  the  rudder,  and  starts  to  add  white  water  to  the  bow  wave. 
At  speeds  above  3  knots,  it  is  pronounced  and  persists  for  several  hundred  yards  astern.  At  high 
speeds,  it  places  a  long,  wide  trail  astern  that  is  a  useable  tool  to  the  OOD  because  it  shows  his 
path  and  course  maneuvers.  Wake  activity  can  also  indicate  sea  state  and  current  information 
that  the  OOD  can  employ  as  he  maneuvers  the  ship. 

Functionally,  engine  order  bells,  in  either  direction,  should  create  a  chum  at  the  rudder. 
Backing  bells  will  force  white  water  to  wash  up  and  over  the  engine  room  hull  forward  of  the 
rudder.  The  higher  the  engine  order  bell  the  more  chum  created. 

Lights  and  lighting  effects  provided  in  the  visual  system  were,  in  general,  less  than 
satisfactory  because  light  size  and  reflective  features  were  either  not  present  or  inaccurately 
represented.  Shipboard  lights,  such  as  the  submarine  identification  beacon,  port  and  starboard 
navigation  lights,  anchor  light,  stem  light  and  bridge  spotlight  were  not  effectively  modeled  in 
the  VESUB  system.  Though  shipboard  lighting  is  predominantly  intended  to  provide  location 
and  recognition  markers  for  other  vessels  underway,  it  also  provides  cues  to  the  OOD  related  to 
the  shiphandling  task.  For  example,  viewing  the  stem  light’s  ‘loom”  allows  him  to  judge  sea 
state.  Other  lighting  issues,  on  hull  and  off,  include  the  effect  of  glare  and  reflection,  as  well  as, 
the  lack  of  shadow  and  texture.  The  submarine  ID  beacon,  for  example,  strobes  the  bridge  area 
and  reduces  the  OOD’s  ability  to  see  other  features  in  the  scene.  This  light  was  not  modeled  in 
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the  VESUB,  however,  it  is  necessary  to  provide  a  realistic  level  of  interference  for  training  night 
operations. 

Effective  implementation  of  lighting  effects  requires  a  significant  increase  in  polygon 
construction,  because  the  illumination  and  shading  within  the  scene  must  be  created  by  filters 
and  masks  placed  over  the  modeled  objects  as  they  come  within  range  of  the  light.  It  is 
recommended  that  this  level  of  detail  be  incorporated  into  the  operational  VE  trainers  that  will 
represent  night  operations  as  a  part  of  their  training  environment. 

While  the  representation  of  masts  and  antennas  was  satisfactory  for  the  VESUB  technology 
demonstration,  these  items  lacked  detail.  Because  these  items  are  all  located  close  to  the  OOD’s 
position  in  the  VE,  their  fidelity  should  be  increased  to  improve  the  trainee’s  sense  of  immersion. 
Areas  of  concern  for  masts  and  antennas  included  accuracy  of  diameter  and  height,  geometric 
shapes  (cylindrical  rather  than  octagonal),  detailed  fittings  for  optical  windows  and  the  like,  as 
well  as  functional  designs  for  specific  masts  such  as,  ESM  and  snorkel  mast  heads.  In  addition, 
these  objects  must  accurately  obstruct  the  trainee’s  view  whenever  placed  in  the  field  of  view 
(FOV),  and  this  includes  during  the  use  of  binoculars. 


Bridge  Area.  Provision  of  additional  details  associated  with  the  submarine’s  bridge  would 
enhance  the  immersion  effect.  The  bridge  suitcase  is  the  only  instrumentation  provided  to  the 
OOD  on  the  bridge  of  the  submarine.  The  modeling  of  the  VESUB  bridge  suitcase  was  effective 
and  met  most  of  the  functional  requirements.  However,  it  also  acts  as  a  communications  center, 
with  a  combined  speaker  and  microphone  system  and  several  circuit  selector  switches  and  a 
collision  alarm  button.  The  complexity  of  the  interface  necessary  to  select  these  switches 
prevented  the  development  of  this  option.  Switch  selection  could  be  a  reasonable  candidate  for 
limited  haptics  application  and  should  be  considered  as  a  means  for  accomplishing  these  types  of 
operations  within  the  VE. 

The  VESUB  compass  adequately  represented  the  shipboard  display,  but  lacked  the  ability  to 
sight  along  the  “Alidade,”  to  mark  bearing  data  to  vessels,  geographic  or  cultural  features,  and 
navaids.  Because  the  OOD  has  few  tools  at  his  disposal,  it  is  important  that  as  many  as  possible 
be  provided  for  his  use.  Inclusion  of  this  function  was  considered,  but  a  ready  interface  was 
lacking.  Voice  and  haptics  interfaces  options  were  considered.  However,  development  was 
outside  of  the  scope  of  the  VESUB  technology  demonstration.  The  alidade  was  not  determined 
to  be  an  effective  tool  for  use  within  a  VE.  Consideration  must  be  given  to  the  limited  motion 
given  the  constraints  of  the  simulated  environment  for  safety  reasons  and  potential  damage  to  the 
HMD. 

VESUB  incorporated  a  dynamic  chart  representation  into  the  bridge  design.  Charts  were 
scanned  and  resized  for  use  in  the  VE.  As  the  scenario  progressed,  the  chart  automatically 
changed  to  provide  the  OOD  with  the  correct  chart  for  his  position  along  the  track.  The  charts 
were  prepared  using  standard  practices  that  would  be  common  to  shipboard  chart  work. 
Additionally,  clutter  that  may  have  slowed  image  processing  and  confused  readability  was 
removed  from  these  images. 
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While  the  VESUB  TEE  participants  liked  the  charts  and  felt  they  were  solid  representations  of 
those  that  would  be  available  for  use,  they  also  felt  that  the  opportunity  existed  for  the  system  to 
support  training  by  placing  a  dynamic  positional  marker  on  the  ship’s  position.  This  was 
considered  a  useful  tool  that  might  be  engaged  in  support  of  the  training  task. 

The  VESUB  harbor  databases  included  two  standard  submarine  ports.  Because  each  ship  is 
responsible  for  preparing  its  own  charts,  the  VESUB  team  considered  methods  that  would  have 
allowed  the  participants  to  use  their  own  charts  during  training  scenarios.  The  use  of  NIMA 
provided  digital  charts  for  direct  loading  was  also  considered.  The  implementation  of  these 
features,  while  outside  of  the  scope  of  the  VESUB  project,  are  considered  excellent  extensions  of 
the  charting  capability  and  are  recommended  for  inclusion  in  follow  on  systems.  The  ability  to 
incorporate  the  real  shipboard  charts  would  allow  trainees  to  exercise  real  world  skills  within  the 
VE,  while  direct  downloading  of  digital  charting  would  support  the  development  of  additional 
harbors  and  might  support  mission  rehearsal. 

A  simplified  maneuvering  board  was  considered  for  inclusion  in  the  visual  scene.  Though 
considered  a  valuable  feature,  the  maneuvering  board  was  eliminated  from  the  list  of  options  due 
to  budget  constraints.  A  maneuvering  board  and  supporting  voice  recognition  requirements 
should  be  incorporated  into  any  future  VESUB  system  design.  This  tool,  as  suggested  by  several 
SMEs  during  VESUB  development,  could  be  designed  into  the  windscreen  display,  fashioned 
after  the  rough  contact  geometry’s  often  drawn  by  the  OOD's.  An  automated  posting  of  data 
could  be  incorporated  into  any  of  these  designs  to  provide  the  trainee  with  the  necessary 
information  to  support  contact  management. 

The  TEE  participants  made  several  suggestions  for  tools  that  might  reasonably  be  included  in 
future  systems.  Consideration  should  be  given  to  the  development  of  haptically-driven  tools, 
potentially  with  force  feedback,  to  allow  for  the  use  of: 

•  Virtual  pen  to  allow  log  and  computational  entries 

•  Virtual  flashlight 

•  Virtual  spotlight 

•  Virtual  microphone 

•  Other  virtual  communications  devices,  such  as  phones  or  hand  sets 

•  The  ability  to  see  a  virtual  body  representation,  with  torso,  hands  and  feet  in  the  scene 

•  Visually  simulated  hands  to  allow  the  trainee  to  point  with  reasonable  accuracy 

Contacts.  The  visual  modeling  of  the  contacts  in  the  VESUB  technology  demonstration  was 
satisfactory.  It  is  believed  that  improved  detail  would  support  immersion  and  should  be 
considered  in  the  development  of  any  VE  system.  Higher  fidelity  of  the  virtual  scene  should 
improve  shiphandling  training  because  it  supplies  the  cues  necessary  to  allow  the  OOD  to 
evaluate  and  execute  his  task.  He  gains  speed  information  from  a  contact’s  bow  and  stem  wave 
activity,  evaluates  range  based  on  deck  and  mast  heights,  and  determines  angle  on  the  bow 
(AOB)  based  on  contrast  and  depth  perception.  Higher  fidelity  models  provide  these  elements, 
and  more,  where  lower  quality  rendering  eliminates  these  cues,  and  with  them  the  OOD’s  ability 
to  make  accurate  judgments. 
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Vessels,  even  small  ones  (at  short  range),  usually  stand  out  in  real  world  situations,  but  they 
often  blended  into  the  virtual  scene  causing  missed  classifications  and  inaccurate  analysis  of 
range,  course  and  anticipated  actions.  Improved  graphical  representation  would  reduce  this 
conflict.  Much  more  emphasis  is  needed  in  accurately  modeling  these  features  for  all  objects. 

The  appearance  of  a  contact’s  lights  can  impact  the  OOD’s  ability  to  perform  in  night  time 
scenarios.  Specific  contact  lighting  problems  included: 

•  placement  of  lights  off-hull  instead  of  on  the  contact 

•  lack  of  surface  illumination  from  light  sources  on  contacts 

•  lack  of  accurate  directional  effects  from  contact  navigational  lights 

•  inability  of  the  system  to  resize  lights  as  contacts  closed  or  opened  range 

Modeling  of  vessels  needs  to  accurately  account  for  deck  and  cabin  lights  as  well  as  working 
lights  and  those  in  companionways  and  passages.  Ships  don’t  generally  operate  in  a  state  of 
“darkened  ship”  and  these  realities  need  to  be  properly  represented  in  the  VE  to  provide  realistic 
visual  cues  that  support  the  task. 

One  of  the  most  significant  contact  issues  was  inaccurate  hydrodynamic  modeling.  Contacts 
operated  without  being  affected  by  wind,  currents,  other  contact  wake  effects,  and  were 
unconstrained  by  geography.  While  there  may  not  be  a  need  to  fully  model  the  specific 
hydrodynamics  of  each  contact,  there  should  be,  as  a  minimum,  standardized  rules  of 
hydrodynamic  interaction  for  each  contact  to  ensure  effective  shiphandling  presentation. 

Contacts  also  need  to  be  controllable  by  the  instructor  while  the  scenario  is  running  because 
the  interactive  nature  of  the  VE  task  prevents  the  instructor  from  anticipating  trainee  actions 
ahead  of  time.  This  capability  was  limited  in  the  VESUB  system,  but  needs  to  be  improved  in 
future  trainers. 

Navigation  Aids.  The  VESUB  project  developed  two  harbor  databases  that  were  based  on 
the  current  charts  and  navigation  information  for  those  locations.  Navigational  aids  (navaids) 
were  identified  by  team  SMEs.  Several  of  the  identified  cultural  features  and  navaids  were 
omitted.  Careful  evaluation  and  consideration  must  be  given  to  all  available  information. 

The  “Navigational  Ranges”  offer  the  best  example  of  placement  errors.  These  key  channel 
markers  are  fixed  placards  that  provide  an  alignment  stripe  as  a  reference  to  channel  center. 

They  are  often  hundreds  of  yards  apart,  and  can  be  seen  several  miles  away.  Minor  errors  in 
placement  on  the  part  of  the  developers  resulted  in  tens  of  yards  of  navigational  error.  The 
primary  cause  of  navaid  placement  errors  was  the  design  of  the  coordinate  system  within  the 
database.  While  these  errors  appeared  negligible  to  the  developers,  they  were  actually  quite  large 
relative  to  the  navigable  water,  some  representing  more  than  20%  of  the  width  of  the  channel. 
Ultimately  these  errors  necessitated  redevelopment  of  VESUB ’s  coordinate  system.  In  addition 
to  the  requirement  for  exact  object  placement,  the  ability  to  add,  delete,  and  move  objects  easily 
is  recommended  for  future  shiphandling  simulations. 
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The  visibility  of  navaids  due  to  contrast,  shadows,  and  textures  plays  a  significant  role  in  the 
shiphandling  task.  Of  particular  importance  is  the  identification  of  navigational  aids  and  vessels 
at  reasonable  distances.  The  background  colors  and  textures  used  in  the  VESUB  visual  scene 
lacked  contrast  and  dimension.  They  sometimes  blended  unrealistically  with  other  modeled 
objects  within  the  scene  (e.g.,  range  markers  blending  into  the  trees  behind  them).  The  trainee’s 
inability  to  see  range  markers,  navigational  aids,  and  geographic  features  made  the  task 
unrealistically  complex. 

The  size  of  navaids,  especially  buoys,  also  proved  to  be  a  problem.  The  environmental 
software  development  package  didn’t  properly  account  for  distance  and  was  also  constrained  by 
pixel  placement  ?t  extreme  range,  causing  size  to  change  disproportionally  to  the  distance  to  the 
object.  Channel  buoys  were  the  worst  offenders,  growing  to  large  towers  within  the  scene 
depending  on  where  the  VESUB  vessel  was  positioned  and  often  dwarfing  traffic  vessels  passing 
them  in  the  channel. 

Lights  on  the  navaids  demonstrated  the  same  problems  noted  previously  for  lights  on  vessels, 
most  notably  lights  at  a  distance  were  easier  to  spot  than  at  closer  ranges  because  they  retained 
their  4-pixel  size  regardless  of  distance.  The  illuminating  effect  of  lights  modeled  within  the  VE 
normally  had  no  physical  shape  or  range  related  luminescence  and  subsequently  appeared  the 
same,  regardless  of  the  viewer’s  distance  from  the  light.  While  this  could  have  been  accounted 
for  by  modeling  improved  visuals  there  would  have  been  a  sizable  increase  in  polygon  rendering 
to  meet  this  need.  If  training  systems  are  going  to  support  nighttime  simulations  this  problem 
will  need  to  be  solved. 

Unlike  stationary  navaids,  buoys  move  with  the  tides  and  currents  varying  as  a  function  of  the 
direction  and  force  of  the  seas  and  the  length  of  their  chain.  This  is  a  noticeable  feature  that 
OOD’s  of  all  ship  types  use  to  evaluate  their  environment.  Buoy  set  and  tending  is  well  defined 
as  the  buoy  leans  against  the  pull  of  the  chain  and  produces  a  swirl  or  eddy  at  its  base.  Though  a 
key  shiphandling  indicator,  this  feature  was  not  developed  and  needs  to  be  incorporated  for 
future  systems. 

All  objects,  stationary  or  not,  are  subject  to  wind  and  storm  damage  and  are  sometimes  lost  or 
drift  out  of  position  (buoys)  and  become  unusable  to  the  OOD.  The  instructor/operator  should 
have  the  ability  to  remove  or  reposition  buoys  within  the  database  to  exercise  this  aspect  of 
shiphandling,  and  to  allow  buoy  modification  and  insertion  of  additional  navigational  aids  to  the 
database. 

Training  systems  are  often  developed  with  a  software  design  freeze  on  improvements  due  to  a 
lack  of  time  or  resources.  The  ability  to  easily  update  systems  is  critical  to  the  life  span  and 
usability  of  the  system  to  support  real-world  environments  of  the  future.  The  ability  to  modify 
the  navigational  databases  for  shiphandling  training  systems  would  allow  trainee’s  to  experience 
real-world  conditions  that  they  can  relate  to  versus  a  static  version  developed  years  in  the  past. 
The  ability  to  modify  these  databases  supports  transfer  of  knowledge  and  experience  and  as  such, 
provides  a  significant  training  benefit.  TTiis  capability  was  not  incorporated  into  the  VESUB 
technology  demonstration  system,  but  needs  to  be  included  in  future  shiphandling  training 
systems. 
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Environment.  VESUB’s  marine  visual  effects  were  created  using  Vega  Marine  software 
from  Paradigm  Simulation,  Inc.  It  was  selected  because  it  was  considered  the  best  marine  effects 
product  available  in  the  market  for  use  on  the  SGI  Onyx  platform.  As  evolving  software,  its 
capabilities  have  improved  significantly  and  many  of  the  issues  relative  to  visual  scene  effects  in 
VESUB  have  been  improved.  Some  issues,  however  remain  significant  to  the  development  of 
VE  systems.  While  time  of  day  was  functional,  nighttime  events  were  less  than  effective  due  to 
the  lack  of  ambient  light  effects  from  the  moon  and  land  based  sources,  as  well  as,  from  vessels 
and  navaids.  Daylight  was  well  modeled,  but  the  sun  was  not  part  of  the  visual  scene  and 
reflective  glare  and  shadow  effects  were  not  present.  Additional  improvements  to  the  surf-zone, 
waves,  background  lights,  light  points,  and  environmental  features. 

The  modeling  of  precipitation  was  incomplete.  For  example,  the  only  indication  of  a  storm 
was  the  sound  of  thunder  and  a  general  darkening  of  the  sky.  Weather  fronts,  such  as  cloud 
masses,  fog,  driving  rain  squalls  were  not  programmed  as  moving  objects  nor  had  any  association 
with  movement  induced  by  the  wind.  While  the  instructor  operator  could  adjust  the  visibility  range 
during  the  scenario,  this  activity  drew  him  away  from  monitoring  trainee  performance  and  would 
be  more  effective  if  automated. 

Of  all  of  the  environmental  issues  that  need  to  be  addressed,  especially  for  a  marine  simulation, 
Earth’s  curvature  is  the  most  significant.  As  ships  approach  land,  or  other  vessels  in  open  ocean, 
they  begin  to  see  the  tops  of  mountains  and  masts  of  ships  from  afar.  This  is  because  the  body  is 
obscured  by  the  curvature  of  the  Earth.  In  the  modeling  and  simulation  arena,  this  aspect  has 
been  overlooked  because  most  of  these  training  environments  have  focused  on  aviation  based 
tasks,  which  are  easily  supported  with  flat  earth  projections,  due  to  the  impact  of  altitude  and 
speed.  Earth’s  curvature  impacts  the  view  of  ships  and  objects  on  the  horizon,  (see  Figure  3)  As 
the  observer’s  height  of  eye,  or  viewing  point,  is  close  to  the  Earth’s  surface,  modeling  within 
this  scene  therefore,  must  include  the  ability  to  see  objects  appear  or  disappear  over  the  visual 
horizon.  The  surfaced  shiphandling  task  provides  a  limited  angular  perspective  that  calls  for 
either  a  curved  earth  model  or  a  modified  surface  view  in  which  objects  are  adjusted  in  a 
height/distance  relationship  as  they  approach  or  subsequently  retreat  from  view.  This 
requirement  may  eventually  drive  effective  geographic  modeling  for  simulation  and  VE 
applications,  but  due  to  its  technically  difficult  nature,  it  was  not  available  for  use  within 
VESUB. 


Distance  to  the  Horizon 


Large  Ship 
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Figure  3.  Earth’s  Curvature  Impacts  View  of  Ships  or  Beyond  the  Horizon 
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Water  Surfaces.  VESUB’s  marine  visual  effects  provided  a  reasonable  representation  of  the 
water  surfaces  and  met  the  needs  of  the  technology  demonstration.  The  nature  of  the 
programming  for  both  hull  models  and  water  surface,  however,  did  not  allow  for  an  accurate 
representation  of  wave  action  at  higher  sea  states.  Choppy  seas  and  white  caps  had  an  artificial 
look  that  detracted  from  the  scene.  More  accurate  sea  state  and  tidal/current  indicators,  such  as 
the  representation  of  eddies  and  tide  rips  also  require  significant  improvements.  Additional 
“Seaman’s  Eye”  elements  that  would  support  the  shiphandling  task  include  bottom  swirls  that 
indicate  ship’s  movement  in  shallows  and  the  creation  of  rip  tides  and  surf  zones,  especially  near 
large  obstructions  such  as,  submerged  structures  and  points,  promontories  and  rocks.  As  surf 
zone  and  shallows  are  being  better  represented  in  recent  revisions  to  these  software  tools,  so  too 
may  tidal  change  indicators  be  improved  to  mark  rise  and  fall  on  cultural  features,  such  as  piers 
and  jetties. 


Auditory  Representation  Requirements 

The  use  of  sound  within  the  VE  enhances  the  trainee’s  immersion.  The  use  of  stereophonic 
sound,  supported  by  two  channel  audio  input  to  the  HMD,  further  provides  an  audio  component 
that  reflects  reality.  The  use  of  audio  cues  in  VESUB  was  an  issue  from  the  project’s  beginning. 
By  leveraging  the  audio  components  used  for  the  voice  interface,  along  with  Audio  Works 
software,  a  small  series  of  environmental  cues  were  implemented.  The  two  mixing  panels  used 
to  control  the  audio  paths  and  amplification  were  set  up  to  feed  both  the  trainee  in  the  HMD,  and 
the  instructor’s  console  speakers. 

It  is  believed  that  greater  realism  and  increased  immersion  will  result  in  improved  training 
with  significantly  less  distractions.  The  VESUB  team  did  not  fully  develop  a  plan  to  support 
environmental  sounds  for  the  technology  demonstration.  However,  the  audio  cues  that  were 
employed  appear  to  have  significantly  enhanced  the  immersion  effect  of  the  training.  The 
hardware  and  software  tools  employed  by  VESUB  allowed  the  developers  to  introduce  audio 
sources  such  as,  wave  and  sea  wash,  wind  (increasing  wind  with  ship’s  speed),  bells  and  whistles 
from  buoys,  and  contact  whistle  signals  into  the  environment.  Although  the  generated  sounds 
were  not  truly  spatial,  these  cues  prompted  the  trainee  to  look  and  act  in  response  to  these  stimuli 
as  they  would  in  the  real  world.  The  need  for  further  development  of  this  capability  is 
considered  essential  to  achieving  the  maximum  training  impact  available  to  a  virtual  system. 
Other  sounds  typical  of  harbor  navigation  and  shiphandling  that  will  enhance  realism  and  should 
be  included. 

Examples  of  harbor  sounds  include: 

•  Homs 

•  Whistles 

•  Bells 

•  Fog  horns 

•  Dynamic  traffic 
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Mechanical  shipboard  noises,  such  as,  the  sound  of  exhaust  blowers  and  diesels, 
communications  circuit  transmissions,  wind  and  sea  noises  (e.g.,  increasing  noise  from  the  own 
ship’s  bow  wave),  and  associated  noises  from  tugs  and  traffic  that  operates  or  passes  within 
reasonable  range  of  own  ship.  These  features  all  need  to  be  spatially  implemented  to  provide 
realistic  scene  accuracy. 

Safety  is  a  paramount  concern  in  the  development  of  training  simulators.  The  experience 
gained  through  the  VESUB  TEEs  demonstrated  that  dangerous  volume  levels  could  be  sent  to 
the  HMD  and  for  this  reason  it  is  important  that  these  system-generated  sound  effects  be 
controllable  from  the  IOS.  A  software  package  is  needed  to  implement  audio  controls  that  can 
provide  operational  safety  features  to  protect  VE  participants. 


Communications  Requirements 

Speech  Recognition.  The  VESUB  system  employed  a  speaker  independent  voice 
recognition  system  with  a  supporting  synthesized  voice  response.  Subjects  operated  the  system 
using  a  press-to-talk  microphone  interface,  the  system  responded  appropriately  and  synthesized 
speech  was  generated  and  output  to  the  trainee  via  head  phones  in  the  HMD  and  speakers  at  the 
IOS,  for  instructor  monitoring. 

BBN’s  voice  system,  “HARK,”  proved  effective  in  this  role  accommodating  variations  in 
volume,  pitch,  and  tone  with  good  functionality,  and  even  allowed  participants  with  heavy 
accents  to  successfully  operate  VESUB.  In  general,  the  accuracy  of  speech  recognition  was 
above  90%  for  correctly  phrased  commands  and  inquiries.  The  VESUB  team  believes  that  90% 
is  not  high  enough  to  support  the  normal  maneuvering  watch  environment  that  trainees  will 
typically  experience  in  the  real  world.  Software  filters  could  improve  this  rate,  but  adjustments 
to  these  sensitivity  levels  will  modify  the  ability  of  the  system  to  understand  all  trainee  voices. 

Trainee  speech  patterns,  such  as,  delays  and  pauses,  higher  pitch,  fast  or  slow  speech,  and 
excessive  volume,  accounted  for  most  of  the  recognition  problems.  Alternatives  to  the  current 
process  might  be  adjustments  to  the  time  allocated  before  the  system  begins  phrase  parsing;  the 
ability  to  suspend  parsing  and  recommence  this  operation  if  a  continued  transmission  is  received; 
linking  the  parsing  process  to  the  open  microphone,  commencing  it  automatically  on  switch 
release. 

Operation  of  the  microphone  button  caused  interference  that  was  interpreted  as  a  command, 
causing  the  system  to  begin  the  process  of  analysis.  The  end  result  was  the  generation  of  an 
erroneous  command  or  a  “say  again  sir”  response.  Mechanical  noises,  such  as,  switch  clicks  and 
electronic  feedback,  should  be  filtered  and  eliminated  from  the  recognition  process.  The  use  of 
software  controls  for  input  and  output  volume  will  improve  the  ability  of  the  instructor  to  factor 
this  out  of  a  given  exercise  or  for  a  specific  student. 

Several  voice  related  system  errors  occurred  which  locked  up  the  software  modules  or 
generated  cascading  synthesized  responses.  This  cascade  of  responses  (often  four  or  more) 
monopolized  the  system  and  prevented  the  OOD  from  acting  to  correct  the  confusion.  At  other 
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times,  when  the  system  was  unable  to  identify  the  received  command  it  became  confounded  and 
locked  up.  While  these  problems  were  easily  accounted  for  in  the  technology  demonstration  they 
will  not  be  acceptable  in  an  operational  system  and  need  to  be  corrected. 

Several  key  phrases  and  words  were  omitted  from  the  library  database,  among  these  are  harbor 
specific  terms,  navigational  aids,  geographic  and  cultural  features,  and  some  standard 
navigational  terms  and  technical  phrases  that  OOD’s  will  employ  in  their  speech.  Examples  of 
these  omissions  are:  Chesapeake  Light,  Cape  Henry,  Fort  Clinch,  and  cardinal  headings  phrased 
as  “course  north,  south,  east  or  west.”  A  detailed  listing  of  possible  phraseology  is  required  to 
support  shiphandling  training.  Development  of  a  more  intelligent  voice  synthesis  system  would 
greatly  improve  voice  recognition  technology  and  the  ability  to  simulate  autonomous  agents. 

Speech  Synthesis.  The  VESUB  speech  synthesis  used  recorded  voice  to  generate  responses 
and  to  make  system  initiated  reports.  This  represented  an  improvement  over  computer  generated 
voice  available  at  the  time  of  software  selection,  but  advancing  technology  may  make  the  use  of 
synthetic  voice  advantageous  over  recorded  speech,  especially  when  it  comes  to  the  ability  to 
modify  response  vocabulary. 

The  recorded  speech  used  in  the  voice  response  system  employed  by  VESUB  proved  to  be  too 
slow  to  properly  represent  response  time  of  stations  subordinate  to  the  OOD.  Timing  in  these 
communications  is  critical.  The  Helm,  for  example,  would  not  delay  his  repeat  back  to  an  order 
until  after  he  had  accomplished  the  task.  He  would  act  on  the  command  and  repeat  it  back  at  the 
same  time.  The  rudder  would  be  coming  over  to  accomplish  the  course  change  as  the  Helmsman 
responded  to  the  OOD.  The  reason  for  this  is  that  the  ship  is  moving  down  track  at  a  rate  of  100 
or  more  yards  a  minute  and  significant  delays  in  time  to  respond  would  result  in  unacceptable 
ship’s  placement.  Response  timing  must  be  improved  to  effectively  represent  a  highly  efficient 
maneuvering  watch  team  supporting  the  OOD. 

The  OOD,  observing  the  environment  as  he  pilots  the  submarine,  generates  orders  based  on 
his  observations,  and  adjusts  these  orders  to  fine  time  his  position  in  the  channel.  When  the 
OOD  is  ready  to  give  an  order,  such  as  in  response  to  a  Navigator’s  marked  turn,  he  must  be 
clear  to  transmit  his  command.  He  may  delay  for  a  single  helm  report,  but  he  can  not  be  held  at 
bay  while  a  series  of  reports  are  transmitted  from  the  voice  buffer.  It  is  important  that  the  OOD 
be  al'e  to  realistically  break  into  the  communications  net  when  needed.  Additionally,  key 
Navigator  reports,  like  “marking  of  turns,”  should  take  priority  over  other  reports  to  allow  the 
OOD  to  act  on  the  track  recommendation.  The  system  must  accommodate  these  communications 
elements. 

VESUB  system  configuration  prevented  the  receipt  of  new  OOD  orders  or  inquiries 
(recognition)  while  the  voice  response  system  was  transmitting  (synthesis).  This  process  needs 
to  be  corrected  so  that  this  conflict  does  not  exist  in  future  systems.  Voice  operations  should, 
however,  be  constrained  to  match  the  real  7MC-circuit  transmission  priority. 

As  the  OOD  dynamically  issues  his  orders  the  virtual  crewmembers  should  change  both 
actions  and  reports  so  that  responses  are  in  consonance  with  the  OOD’s  requirements.  This 
parallel  set  of  actions  should  also  drive  modifications  to  voice  responses  that  are  in  the  buffer’s 
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que.  A  new  ordered  course,  rudder  order,  or  engine  order  should  override  any  action  and  report 
that  is  pending,  as  a  real  Helmsman  would  not  act  on  and  report  an  element  that  has  been 
overridden  by  changing  status,  events,  or  orders.  As  an  example,  an  All-Stop  that  is  modified  to 
an  All-Back  2/3  should  not  be  acted  on  and  reported,  as  the  All-Back  2/3  takes  precedence  in  the 
order  that  it  was  given.  Ultimately,  some  ability  for  the  system  to  prioritize  actions  and  reports 
must  be  considered  in  the  programming  of  technologically  advanced  virtual  training  systems. 
Simple  word/phrase  response  structures  will  not  suffice. 

The  synthesis  process  is  also  part  of  the  response  cascade  issue,  in  that  this  side  of  the  system 
acts  on  the  direction  of  the  recognition  process,  and  it  may  be  able  to  be  addressed  from  the 
synthesis  side  of  the  software.  The  solution  may  be  to  limit  the  number  of  responses  (literally) 
that  can  be  selected  for  a  single  order.  More  review  of  this  issue  is  needed. 

Sound  System.  The  VESUB  sound  system  was  a  hardware  add-on  to  the  SGI  INDY  desktop 
computer.  It  worked  in  conjunction  with  the  audio  effects  provided  by  the  Audioworks  software 
package  and  was  suitable  for  the  technology  demonstration.  However,  this  system  is  not  well 
suited  for  a  primary  trainer  because  it  required  a  host  of  cables  and  several  adjustable  components 
to  remain  unprotected  in  the  open.  This  design  incorporated  audio  channel  volume  control  slide 
bars,  which  were  easily  knocked  off  their  intended  levels.  A  solution  for  this  problem  is  a  software 
controller  (like  those  found  on  many  CD  players  in  personal  computers)  to  provide  adjustments  to 
audio  output  levels,  filtering  and  balance. 


Scenario  Construction  Requirements 

VESUB’s  scenario  construction  capability  was  based  AME’s  Virtual  Ship  software.  These 
applications  located  several  layers  deep  in  the  VESUB  architecture,  provided  the  necessary  tools 
for  scenario  construction  and  modification.  The  development  of  training  scenarios  dictates  that 
the  instructor/operator  design  a  problem  around  learning  objectives  that  focus  on  specific  events 
and  key  tasks  that  the  trainee  must  master.  Developing  scenarios  and  managing  them  during 
training  was  a  key  feature  proposed  for  the  VESUB  project.  This  functionality  was  intended  to 
allow  the  trainee  to  enter  into  a  training  session  that  would  begin  with  a  reasonable  set  of 
circumstances  and  evolve  as  a  function  of  the  trainee’s  actions.  This  process  must  be  a  complex 
and  dynamic  one  that  automatically  adjusts  the  simulated  scenario  events  to  match  trainee  driven 
interactions,  and  one  that  allows  the  instructor  to  modify  the  scenario  in  real  time  to  meet  these 
needs. 

Setting  Initial  Conditions  with  the  Scenario  Development  Interface  (SDH.  VESUB  had 
several  modules  that  had  to  be  mastered  by  the  operator  before  he  could  effectively  produce 
scenarios.  The  SDI,  included  screens  to  initially  develop  and  modify  scenarios;  set  initial 
conditions  for  ownship;  establish  the  basic  operating  variables  for  the  simulation;  and  an 
interface  to  set,  control,  and  modify  traffic  vessels.  These  elements  are  independently  developed 
and  then  linked  together  for  each  scenario.  Initial  conditions  could  either  be  selected  by  recalling 
previously  constructed  scenarios,  or  by  initiating  construction  of  a  new  scenario.  This  allowed 
the  operator  to  save  development  time  by  leveraging  established  scenarios  or  to  build  an  entirely 
new  scenario  to  meet  training  objectives. 
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While  the  VESUB  scenario  development  process  proved  acceptable  for  use  in  the  technology 
demonstration,  its  complex  nature  was  difficult  for  most  operators.  A  simplified  design  is 
necessary  to  support  effective  scenario  development.  The  solution  may  rest  in  either  a  more 
functional  graphical  user  interface  (GUI)  or  pull-down  menu  design. 

Programming  of  Contacts.  Contact  performance  was  of  concern  to  the  operator,  whose  task 
was  to  try  to  optimize  system  capability  during  scenario  development.  The  operator’s  tools  must 
allow  him  to  accurately  place  objects  into  the  exercise  area,  and  he  must  be  reasonably  assured 
that  they  will  do  what  he  expects  once  they  are  entered.  Contact  placement,  operating 
characteristics  (hydrodynamics),  and  time  driven  commands  (waypoints)  must  be  dependable 
and,  when  running,  must  execute  as  expected. 

Though  the  VESUB  operator  who  developed  scenarios  was  able  to  effectively  overcome  many 
of  these  issues,  the  scenario  development  process  was  never  refined  to  the  point  desired.  Contact 
placement  and  management  remained  a  problem  throughout  the  project.  While  the  expertise  of 
the  primary  operator  allowed  effective  scenario  development,  the  average  operator  would  have 
been  much  less  successful. 


Instructor/Qperator  Station  Design  Issues 

The  IOS  implemented  for  VESUB  was  leveraged  from  AME’s  Virtual  Ship  product,  which 
supported  surface  shiphandling  training.  AME’s  initial  IOS  design  for  VESUB  varied  only 
slightly  from  their  baseline  device.  System  operation  through  this  IOS  was  functional,  however, 
it  was  neither  intuitive  nor  submarine  oriented.  Terms  and  images  that  appeared  on  the  IOS 
reflected  its  surface  ship  background,  and  many  of  these  had  no  submarine  application. 

Ease  of  operation  was  considered  essential  by  the  team  because  the  instructors  running 
VESUB  were  not,  and  would  not  be,  experts  on  the  system.  IOS  design  and  usability  was  the 
focus  of  a  system  analysis  reported  in  Hays,  et  al.  (1997)  which  provided  additional  details  on  the 
functionality  and  design  features  of  the  VESUB  IOS.  The  goal  of  the  team  was  to  have  an  IOS 
that  would  allow  ease  of  system  operation  for  all  assigned  instructors,  and  that  would  effectively 
support  scenario  management  throughout  the  training  cycle.  In  the  end,  the  IOS  design  was  a 
compromise  between  the  desired  functionality  and  operability  and  the  limitations  imposed  by 
time  and  financial  constraints.  The  team  had  intended  to  move  to  a  single  large-screen  display 
for  all  IOS  functions,  driven  by  pull  down  menus  and  screen-in-screen  projections.  Instead  the 
VESUB  IOS  remained  on  two  mid-size  screens  requiring  the  operator  to  shift  from  one  to  the 
other  to  manage  training  events. 
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CONCLUSIONS  AND  RECOMMENDATIONS 


The  VESUB  R&D  technology  demonstration  system  integrated  and  fielded  a  content  rich 
training  system,  capable  of  effectively  training  a  complex  task  for  trainees  with  varied  skill 
levels.  The' results  of  the  TEE,  one  of  the  first  conducted  for  a  virtual  environment  trainer,  and 
the  lessons  learned  throughout  the  VESUB  development  process  point  to  several  important 
conclusions  and  recommendations: 

•  VESUB  provides  effective  shiphandling  training 

•  Team  communications  is  a  must  in  the  development  of  complex  systems 

•  Legacy  based  system  development  must  be  closely  evaluated 

•  Configuration  Management  is  essential  for  success 

•  Complex  scenes  require  sufficient  fidelity  to  support  training  requirements 

•  VE  offers  unique  presentation  capabilities  that  should  be  exploited 


VESUB  PROVIDES  EFFECTIVE  SHIPHANDLING  TRAINING 

Data  from  the  TEE  on  eleven  of  fifteen  variables  showed  significant  learning  in  a  variety  of 
shiphandling  skill  areas.  It  can  be  said  with  confidence  that  VESUB  technologies  can  provide 
effective  training.  However,  a  training  system  is  far  more  than  just  technologies.  It  can  not  be 
stated  too  strongly  that  a  training  system  will  only  be  effective  if  it  is  used  correctly.  Care  must 
be  taken  to  implement  the  technologies  in  VESUB  in  a  manner  that  is  consistent  with  known 
learning  principles. 


TEAM  COMMUNICATIONS  IS  A  MUST  IN  THE  DEVELOPMENT  OF  COMPLEX 
SYSTEMS 

To  effectively  manage  a  technically  complex  and  content  specific  project,  the  lines  of 
communication  must  be  established  at  the  start  of  the  project  and  maintained  throughout.  This  is 
often  a  difficult  task,  even  when  the  entire  team  is  located  within  the  same  lab  or  office,  and  it  is 
made  more  difficult  when  the  team  members  are  spread  out  over  several  sites.  Creating  a  team 
communications  plan  including  communications  paths,  delivery  plans,  information  flow  and 
routine  project  meetings  is  essential  to  the  success  of  the  team  process.  Implementation  of  this 
plan  allows  members  to  effectively  interact  to  share  vital  information  before  incorrect  decisions 
are  made.  Failing  to  formalize  this  process  can  result  in  lost  data,  team  conflict,  false  starts,  and 
ultimately  result  in  project  delays  that  stem  from  these  issues. 


LEGACY  BASED  SYSTEM  DEVELOPMENT  MUST  BE  CLOSELY  EVALUATED 

While  saving  project  resources  is  an  attractive  motivator,  employment  of  a  legacy  system  as 
the  basis  for  a  new  system  may  not  be  the  best  solution  for  long-term  development.  The  system 
developer  for  VESUB  was  selected  because  they  had  a  strong  background  in  maritime 
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simulation,  especially  in  harbor  navigation  and  piloting.  It  appeared  a  simple  task  to  convert  the 
Virtual  Ship  software  into  a  Virtual  Submarine,  but  this  conversion  proved  more  difficult  than 
expected.  The  programmers  focused  on  keeping  the  structural  integrity  of  the  base  system  and 
opposed  changes  that  would  have  made  it  more  suitable  to  the  submarine  domain. 

Additionally,  there  should  be  a  concern  for  the  continued  use  of  legacy  systems  that  are  not 
evolving  with  technology.  The  VESUB  architecture  employed  a  layered  design  that  integrated 
software  packages,  one  atop  another,  in  a  complex  design.  Driven  by  the  legacy  structure, 
VESUB  employed  the  same  software  tools  that  had  proven  effective  for  Virtual  Ship,  without 
consideration  for  new  tools  that  had  been  developed  in  the  interim. 


CONFIGURATION  MANAGEMENT  IS  ESSENTIAL  FOR  SUCCESS 

VESUB  hardware  and  software  development  was  accomplished  at  AME’s  primary  site  in 
Arlington,  VA.  Revisions  to  the  software  were  transferred  electronically,  to  the  NAWCTSD 
VESUB  lab  for  incorporation  into  the  system.  Several  differences  were  noted  between  the 
performance  of  these  two  systems,  and  delays  were  experienced  based  on  these  differences. 
These  problems  were  isolated  to  systems  configuration  variances  between  the  two  sites,  and 
work-arounds  were  built  to  overcome  each  problem.  Systems  efficiency  could  have  been 
improved,  however,  had  strict  configuration  management  procedures  been  employed.  It  is 
recommended  that  projects  establish  and  adhere  to  a  specific  hardware  and  software 
configuration  plan.  When  multiple  sites  are  used  for  developing  and  testing  systems,  hardware 
suites  must  be  duplicated  exactly  to  ensure  configuration  and  operating  consistency.  Software 
applications  employed  will  also  need  to  be  controlled,  ensuring  that  titles  and  revisions  are 
identical  and  that  any  bridges,  jumpers  or  patches  installed  at  one  site  are  also  installed  at  the 
other  sites.  This  problem  may  not  be  completely  overcome  through  configuration  management 
procedures,  as  many  high-end  computer  systems  are  unique  and  will  not  be  identical  even  when 
carrying  the  same  model  name  and  number,  but  it  will  be  greatly  reduced  through  this  strategy. 


COMPLEX  SCENES  REQUIRE  SUFFICIENT  FIDELITY  SUPPORT  TRAINING 
REQUIREMENTS 

Development  of  an  image  rich  environment  for  a  VE  based  training  system  requires  that  the 
developers  achieve  an  understanding  of  the  visual  scene  being  managed  and  that  they  have  an 
appreciation  for  the  level  of  fidelity  needed  to  engage  the  trainee  in  the  virtual  world.  While  full 
photo-realism  is  clearly  not  called  for,  there  must  be  sufficient  attention  to  detail  so  that  the 
trainee  focuses  on  the  training  tasks  presented  and  not  on  the  nature  of  the  scene  being  viewed. 
Textures,  resolution,  and  contrast  between  objects  in  the  scene  provide  critical  cues  that  allow  the 
training  subject  to  operate  in  VE  without  raising  questions  as  to  what  he  has  seen.  Examples  of 
conflicting  image  elements  include:  1)  navigational  aids  that  are  not  properly  proportioned;  2) 
unrealistic  or  conflicting  textures,  such  as  background  vegetation  and  navigational  range  markers 
(red  and  white  markers  blending  with  brown  and  green  vegetation);  3)  lack  of  contrast  between 
objects  or  surfaces,  such  as  small  boats  and  the  water’s  surface;  and  4)  as  well  as  a  lack  of  light, 
shade  and  shadow  within  the  scene.  Developers  and  modelers  need  to  pay  attention  to  these 
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details  as  they  build  the  scene  so  that  their  negative  impact  is  minimized,  and  the  trainee  sees  the 
cues  that  he  or  she  needs  to  succeed  in  the  training  task. 

State-of-the-art  image  generators  provide  the  capability  to  run  multiple  channels  from  the 
same  database.  Each  of  these  channels  can  be  assigned  a  unique  viewing  perspective  (e.g.,  OOD, 
Lookout,  periscope  view).  The  same  database  that  provides  the  visuals  also  provides  a  geo- 
situational  screen  (bird's  eye  view)  that  can  also  be  used  to  drive  other  displays  (e.g.,  radar,  etc). 

It  is  strongly  recommended  that  future  systems,  such  as  NAWCTSD’s  VESUB-2000  and  SPAN- 
2000,  fully  exploit  this  multichannel  capability,  and  that  distributed  systems  or  networked 
systems  that  share  scenarios  employ  a  common  image  generator  and  positional  database,  rather 
than  attempting  to  synchronize  two  or  more  hardware  platforms  to  meet  these  needs. 


VE  OFFERS  UNIQUE  PRESENTATION  CAPABILITIES  THAT  SHOULD  BE 
EXPLOITED 

The  unique  nature  of  VE  allows  the  developers  and  the  instructional  specialists  to  use  new 
instructional  approaches.  As  an  example  of  this,  VESUB  has  the  potential  for  the  OOD  to  shift 
his  eye  position  from  one  point  on  his  submarine  to  another,  even  from  his  vessel  to  another. 
This  feature  could  transport  the  trainee  to  the  other  ship  so  that  he  would  gain  a  more  complete 
perspective  of  the  navigational  problem  and  better  understand  the  impact  of  his  actions  on 
approaching  contacts. 

Limited  only  by  imagination,  VE  will  allow  training  systems  to  demonstrate  complicated 
theory  and  technical  specifics  to  better  meet  training  objectives  in  an  interesting  and  innovative 
way.  Properly  employed,  these  instructional  capabilities  may  prove  to  be  the  most  important 
aspect  of  the  use  of  virtual  representations  in  the  training  field. 
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APPENDIX  A 

VESUB  Hardware  and  Software 


HARDWARE 

Main  Computer  System:  Silicon  Graphics  Onyx  Deskside 

•  Four  RIO, 000  CPUs 

•  256  Mbytes  RAM 

•  One  Infinite  Reality  Graphics  Pipe  with  Two  Raster  Manager  Boards  (16  MB  Texture 
Memory) 

•  Scene  Refresh  Rate  at  30  Hz 

•  Capable  of  Displaying  Approximately  21,000  Polygons  (fully  Z-buffered  and  anti-aliased) 

Instructor/Operator  Station  (IOS): 

•  Two  Silicon  Graphics  INDY  Desktop  Computers _ 

Head  Mounted  Display  (HMD):  n-Vision  Datavisor  HiRes 

•  Resolution:  1280  x  1024  pixels 

•  Field  of  View:  40  degrees  horizontal  and  30  degrees  vertical  (capable  of  stereo-optics  for  up 

to  70  degrees  horizontal  view) _ _ 

Head  Tracker:  Polhemus  3  space  Fastrack  (Magnetic) _ 

Printer:  Epson  Stylus  800,  color  Inkjet _ _ 

Sound  System: 

•  Two  Radio  Shack  SSM60  Stereo  Sound  Mixers 

•  Two  Rane  MSI  Microphone  Amplifiers 

•  Two  Radio  Shack  Dynamic  CB  Microphones,  P/N  21-1172 

•  Two  Radio  Shack  Speakers,  Cat.  No.  :  40-1324 


SOFTWARE 


Visual  Scene: 

•  Models  and  Terrain  Created  Using  ModelGen2  from  Multigen,  Inc. 

•  Real-time,  Interactive  3-D  Scene  Generation  Controlled  by  SGI’s  IRIS  Performer 

•  Marine  Visual  Effects  Created  Using  Vega  Marine  from  Paradigm  Simulation,  Inc. _ 

Instructor/Operator  Station  (IOS)  Interface: 

•  IOS  Screens  Created  Using  Visual  Applications  Builder  (VAPS)  from  Virtual  Prototypes, 
Inc. 

•  Windows  in  SIMGEN  and  Start-up  Screens  Created  with  X-Designer  Release  4.  5  from 

Imperial  Software  Technology  Limited  and  Data  Views  Corporation _ 

Voice  Recognition  and  Synthesis: 

•  HARK,  developed  by  Bolt,  Baranek  &  Newman,  Inc.  Implemented  by  UFA,  Inc. _ 

Audio  Effects: 

^^^Audioworks^omP^adi^n^imulatiomlnc^^^^^^^^^^^^^^^^^^^^^ 
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